Views integration: feeds_source base field is an array, should be scalar

Please, can you export your view?

Sorry, you are using feeds to process your feeds, you should ask in this project.

Support request.

Closing after prolonged period of inactivity.

I'm getting this same error, though in line 96 of views/includes/query.inc now.

Using: Feeds 6.x-1.0-beta3 with Views 6.x-2.11. Occurs whenever a "Feeds source: Source Source" field is added to the view.

The problem is that Feeds is passing $base_field as an array, resulting in the illegal offset error.

      $this->fields[$base_field] = array(
        'table' => $base_table,
        'field' => $base_field,
        'alias' => $base_field,
      );

Hm, how then are we going to reflect the fact that the primary key is two fields in feeds_source ?

I'm not a pro with Views at all, but looking at: http://drupalcontrib.org/api/function/hook_views_data/6, I'm assuming that $data['feeds_source']['table']['base']['field'] is supposed to be the primary key of the table, right?

But the view seems to work just fine and doesn't throw any errors if I change line 23 in feeds/views/feeds.views.inc from:

'field' => array('feed_nid', 'id'),

to:

'field' => 'feed_nid',

Am I missing something? (Probably ;) )

Yeah, that's clear. Thing is that I *assume* that base field needs to be unique but 'feed_nid' nor 'id' are unique, while ['feed_nid' | 'id'] is.

Again, not a pro, but I though that base field had to be the name of an actual column in your table. I'm curious to see what would happen if you just left base field blank, since you're not building any relationships that need the primary key.

Above my paygrade/skill level at this point. The change I made above works for my use case. I'm happy to test any patches that come from this. Thanks for all your work, alex_b, and please let me know how I can help!

Just talked to some Views experts, here is what's going on:

Tables that should be Views base tables (feeds_source in this case) MUST have a primary key that consists of only one field, that's because base_field can be only one field and must be a PK.

This means that in order to fix this issue, we need to add an auto increment field (source_id I suggest) to the table and make it the PK instead of id | feed_nid. This is also the field that we will pass on to Views as base_field. #10 will break in cases where there is more then one $feed_nid. That's for instance when you use two standalone importers (not attached to nodes), both of their feed_nid would be 0.

That makes senses. Thanks for the follow up and detailed explanation. I'll keep following this ticket and will test any patches that result from this. Again, please let me know if there's more that I can do. Sorry that I'm not a good enough developer to lend a bigger hand.

-Sean

If you have any magic powers to send programmers this way, I'd appreciate it :-)

Well, I should say that if all you need is a patch with a hook_update_N function written to add a new primary key field to the schema, I can do that...But I'm guessing this requires changing references to your current key all over the place. Right?

But I'm guessing this requires changing references to your current key all over the place. Right?

Those references shouldn't be hard to track down, at least you could give it a try :)

Okay. Will do. I'm on vacation next week (not that everyone on the forum needs to know...). The week after next I can this a try!

Okay, here's my first stab at the patch. Seems to be working for me, but admittedly I haven't done a ton of testing.

Updated patch against 6.x CVS. Modified hook_schema() to match change. Also named the new pkey source_id instead of fid.

Is there a reason to add an index to replace the old primary key?

      'id_feed_nid' => array('id', 'feed_nid'),