I have a very specific use case for Entity Reference that implies having a reference field for every entity type, and I thought it would be nice if the 'target_type' setting would be available in the field instance settings, thus allowing me to work with only one reference field instead of one field per entity type.

Finally got around to finish up the work on this (first mentioned in #1319040-6: Remove "target_type" column from db), and it's actually working pretty good.. until you get to the Views integraton. It seems that Views relationships needs to work without an instance, and that's where things blow up in my patch (entityreference_field_views_data()).

I'm going to wait a few days and ask about this, but I'm pretty sure there's no workaround and I'll probably won't fix it myself. Just wanted to get the patch here so others won't waste their time if they have a similar use case.

Comments

amateescu’s picture

FileSize
21.44 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entityreference_target_type_in_instance-1.patch. Unable to apply patch. See the log in the details link for more information. View

This one works better (after a chat with @dereine in IRC), but some relationships seem to work better than others, and if you use a Node reference relationship in a field, things blow up again :)

bojanz’s picture

I have the same need in commerce_affiliate. Each commission bundle might reference a different parent entity type.
The relationship part in this approach is hard, because a single join is no longer enough, you might need several (a view displaying nodes of several types, each with a field instance pointing to a different entity type), so I'm guessing that needs additional code (if it's possible at all, I'm not really an expert on Views relationships).

A workaround I was thinking about was to have a reference field per entity type instead of a single commerce_parent_entity field across all bundles.
But that makes things complicated in Views later on... So I'm definitely interested in pushing this forward.

amitaibu’s picture

> A workaround I was thinking about was to have a reference field per entity type instead of a single commerce_parent_entity field across all bundles.

From OG experience (i.e. #1342632: Deprecate OG group entity) I can say that field per entity type, makes things much easier with integrating with other modules.

Damien Tournoud’s picture

Some code comments in there talk about an update function, but there is none?

amateescu’s picture

Yep, there is none at the moment :) I intended to write that after I was sure that the Views part is possible..

Damien Tournoud’s picture

@Amitaibu, @bojanz: do you think it's a good idea to push this further? Would it be of any interest for OG?

bojanz’s picture

I went with parent_entity_id, parent_entity_type properties for Commerce affiliate. It's a pretty specific use case where the data is filled by Rules in most cases.
A field per entity type was too much complexity for its worth.

It's all a question of how much work this actually is in order for it to be completed.

amateescu’s picture

Well, there's not so much work left here. I can do the update function, but someone with better understanding of views relationships should look at that part..

amitaibu’s picture

> A field per entity type was too much complexity for its worth.

I think that if you guys have a use case, then obviously it's needed. It should be noted though, that modules such as Views, expect the values to belong to one entity, so it's probably need to be a last resort referencing multiple entity types.

colan’s picture

Status: Needs review » Needs work

My use case is that I've got different types of book sections implemented as different content types (hierarchical data, as discussed elsewhere). So the parent field in each node is an Entity Reference field, but as I've got different content types here, it should be possible to share the field with different parent types. I'd really like to see this move forward.

What confused me is that the target chooser is on both the field settings and the instance settings pages. At the time, I thought it would be reasonable to assume, then, that the field setting would set a default target type which could be overridden by each instance setting. Clearly, that's not happening as changing the instance target changes all the targets. Therefore, the target chooser shouldn't be on the instance settings page until such time as it doesn't affect other instances. If this setting weren't on the instance settings page, I wouldn't have attempted this; I would have simply stuck with completely different fields. So this is also a UI problem.

I'm not saying we should actually take away those UI bits, but that it's causing confusion while there. Let's just implement the missing functionality. Setting this to "needs work" until the Views goodness can be figured out.

EDIT: Sorry folks. I just realized that the field set at the bottom of the "Edit" tab is for field settings. I thought everything on that tab was for instance settings. So it appears as though field settings are both (1) in the Edit tab and (2) in the "Field settings" tab. So this is actually the UI problem, not what I mentioned above. ;)

joachim’s picture

> I have a very specific use case for Entity Reference that implies having a reference field for every entity type, and I thought it would be nice if the 'target_type' setting would be available in the field instance settings, thus allowing me to work with only one reference field instead of one field per entity type.

When you say target type, is that entity type or entity bundle?

Because if the aim is to have different instances of the same field point to different entity types, and then have views relatioships, then those relationships won't work.

I discovered this recently when trying to make a views relationship that wasn't always to the same entity type. The 'base' in the relationship definition in hook_views_data() must be fixed, otherwise the Views UI can't tell what new entity's fields to make available.

colan’s picture

If we're stuck with a single entity type, would there still be a Views limitation if different instances referenced different bundles (same type)? So, for example, the field settings would contain "node" as the entity type, but in the instance settings, one could select the desired content types / node bundles.

joachim’s picture

> would there still be a Views limitation if different instances referenced different bundles (same type)?

No, because your relationship would go to the same table.

> So, for example, the field settings would contain "node" as the entity type, but in the instance settings, one could select the desired content types / node bundles.

Yes, this would be possible.

colan’s picture

Title: Move 'target_type' to the field instance settings » Move target bundle to the field instance settings

Updating title.

andypost’s picture

Issue makes sense, this very useful to have only one field to attach it to different bundles with different settings.

For eaxmple implementation:
1) 3 node types: a different type of goods
2) each has the er-field (template_entity) to reference a own node-type

for now I need to make 3 different fields because there's no ability to store allowed bundles in instance settings.

I think we should move all field level settings to instance settings. Looks like views should not be modified except a storage for it's settings.

hook_update_n will move current settings to instance level

but have no idea about tests...

caschbre’s picture

I'm interested in having the target type be at the field level and the target bundle at the instance level.

Where are we at with this? Is this something worth trying to push forward / patch?

alfaguru’s picture

I have been looking at the equivalent issue when wanting to use different views across instances. Before doing anything it would seem wise to carry out some preparatory refactoring so that retrieval and updating of settings is properly encapsulated. In other words the plugin base classes for behavior and selection should have methods like getSetting($name), setSetting($name, $value) with the default implementations working as now.

Once that's been done it would make it a lot easier to make this change and similar ones I'd like without breaking existing field settings.

DuaelFr’s picture

I also need to be able to use different views accross instances.

Does someone know a workaround for this use case ? Does an alter hook exists to allow to change the view/display at runtime ?
The entities I have to store have the same bundle but not the same state and I would like to use only one field instead of a dozen.

BrightBold’s picture

I confess I don't understand the implications of making this change from a module maintainer's perspective, but as a sitebuilder using Organic Groups, I would love to see the Target Bundle settings moved to the field instance. This would allow different target bundles per entity when needed, without having to create duplicate Views and Rules to act on group content which you want to be treated basically the same as other group content in every way except for the target bundle. This has been discussed at length over at #1674078: Target Bundles settings not retained for content types so I'd love to see this issue get some traction over here.

xanderz’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1: entityreference_target_type_in_instance-1.patch, failed testing.

RoSk0’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
15.12 KB

Moved target bundle setting to field instance settings.
This is not a rewrite of previous patch.
Didn't touched tests for now because I'm not very good at those and want to bring any other possible issues with the patch to the surface before spending heaps of time on tests.

There is one issue that is already known - behaviors. They store its settings in both instance and field and I'm not sure how to proceed with them. It looks like behaviors is more on a field level then instance...

Status: Needs review » Needs work

The last submitted patch, 22: entityreference-tagret_bundle-1340098-22.patch, failed testing.

RoSk0’s picture

Just realized that testing existing configurations would be hard without update so here we go - added update.

RoSk0’s picture

Spent some time to get more understanding of how things work here.
It would be perfect to have target bundle configured on instance level but...
If we will have a closer look at this we will see that target bundle is a "selection handler" configuration and "selection handler" itself is a field level thing. Now we have a problem: we need to select "selection handler" for field and then store it's configuration in the instance, but what to do with views which have no idea about field instance when you try to configure this field as filter? Default "Simple" selection handler can just show you full list of entities of target type without bundle filtering, which is far from optimal but at least working, but what about views selection handler? Without information about which view to use for selection we are blind.

The only sane way I see to move forward at the moment is:

  1. Leave selection handler select(which selection handler to use) on field level
  2. Move selection handler configuration to field instance settings
  3. When it comes to using selection handler without it's setting have "select all" for simple handler and "select none" for views handler
  4. Create follow up to this issue to create views filter handler to allow to configure same settings as in field instance but inside view, this will mean that we will still be able to select target bundles and entityreference view

There is already an issue related to mentioned follow up - #2618590: Allow for multiple target bundles in views selection filter handler.

Will try to implement proposed solution meanwhile and hope to hear back from maintainers soon.

RoSk0’s picture

Status: Active » Needs review
FileSize
15.4 KB

Moved selection handler settings to field instance config.

Patch contains regression on form level - selection handler settings form is not updated with ajax when selection handler changed on field instance settings page. Failed to handle that, need some help.

Status: Needs review » Needs work

The last submitted patch, 26: entityreference-1340098-26.patch, failed testing.

RoSk0’s picture

Status: Needs work » Needs review
FileSize
21.13 KB
5.73 KB

Updated patch version with the following fixes - handler test, Entity Reference UI tests.

Patch still contains regression on form level - selection handler settings form is not updated with ajax when selection handler changed on field instance settings page. Failed to handle that, need some help.