Iterate each field by entity type in field selector instead of grouping together as Field

It would be possible to add each field to each entity type it's attached to, but this might cause to blow up the views_data a bit.

I agree with michaelfavia that this would be helpful. I have a simple View with three fields and no relationships. One of those fields is assigned to both node and user entities.

The two fields only on the node entity query and render their node values.

The one field on both node and user entities queries and renders the user value.

It seems I can force the field to use the node value by making a relationship to the node revision. However this took me a awhile to figure out and seems like overkill.

Set as task.

Just some questions

[21:39] <dereine> okay about the fieldapi integration bug with fields on multiple entity types
[21:40] <-- double_ has left this server (Quit: double_).
[21:40] <dereine> i'm wondering how we can make the change without breaking existing views, breaking existing templates etc.
[21:40] <dereine> so in theory 'moved to' would be a perfect helper, but to what is the question
[21:40] <dereine> let's assume we have a field to node, and user, to which entity should the field be moved?
[21:41] <dereine> or should it not be moved and the info should keep a flag and decide on the fly and prefer always the base table?

The chat

[22:11] <merlinofchaos> dereine: Yeah that's a tough one.
[22:13] --> SergeL has joined this channel (~Adium@dslb-092-075-207-191.pools.arcor-ip.net).
[22:13] <dereine> why has to be the world so complicated
[22:16] <merlinofchaos> dereine: one option is to prefix the tablename with the entity (but only for multiple entities) and put a 'moved_to' for the 'base' with the 'first' entity. Actually maybe we wouldn't even need to do that.
[22:16] <merlinofchaos> dereine: Maybe we allow the first entity in the list to use it unprefixed.
[22:16] <merlinofchaos> And then additional entity types get a prefix.
[22:16] <dereine> the question is what's the first entity
[22:16] <dereine> this will probably node, because node < user?
[22:17] <merlinofchaos> It's...whatever Drupal gives us for the order?
[22:17] <merlinofchaos> There's an array of entities, right?
[22:18] <-- greggles has left this server (Ping timeout: 252 seconds).
[22:18] <dereine>   foreach ($field['bundles'] as $entity => $bundles) { should better use $entity_type as variable name
[22:19] <merlinofchaos> right. So I guess the question is...is that list static? When you add that field to a new entity/bundle does it get added to the end of the list, or is that list sorted?
[22:20] <dereine> field_read_instances?
[22:20] <Druplicon> field_read_instances: Reads in field instances that match an array of conditions. => field_read_instances($params = array(), $include_additional = array()) => http://api.drupal.org/api/function/field_read_instances/7
[22:21] <dereine> this seems to do a pure query, so if you add a new one, it has a higher priority
[22:21] <merlinofchaos> dereine: ok those are unsorted so yes, it should come in database order.
[22:21] <merlinofchaos> So...we *should* be able to rely on that.
[22:21] <dereine> and this is the primary key by default?
[22:21] <dereine> great
[22:22] <merlinofchaos> Yes.
[22:22] <-- bojanz has left this server (Read error: Connection reset by peer).
[22:22] <-- davidstrauss has left this server (Ping timeout: 246 seconds).
[22:23] <dereine> one thing we might should fix is to add $entity_tables to each definition of a field
[22:24] <dereine> because one global big info would be enough
[22:24] <merlinofchaos> dereine: It doesn't really work. Let's say I've got a 'node' base table. By default, 'user' and 'node' base tables are available. Which do you select?
[22:24] <merlinofchaos> Naturally you'd say 'node' because it binds tighter, but it gets weirder when I've got some arbitrary table that has implicit joins to 'node' and 'user'.
[22:25] * merlinofchaos hopes that makes sense.
[22:25] <-- sarah_p has left this server (Quit: Going to enjoy life away from the screen.).
[22:25] --> voxpelli has joined this channel (~anonymous@83.176.255.215).
[22:25] <merlinofchaos> Oh wait, here's a real life example. Let's say I've a field that's on both 'user' and 'comment'. (I know, highly unlikely). 'user' and 'comment' are both available implicitly on 'node'

Subscribing.

Ok, so it turns out that the fields are actually working. Implicit relationships might be the cause of them not working, but I can't reproduce it.

However, labelling still sucks. This patch fixes the labelling issue. Thoughts?

I committed a version of this patch that includes base table filtering so that aliases won't appear for irrelevant base tables. There's still some duplication but that should be generally acceptable.