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.

Files: 
CommentFileSizeAuthor
#1 entityreference_target_type_in_instance-1.patch21.44 KBamateescu
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 ]
entityreference_target_type_in_instance.patch21.25 KBamateescu
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entityreference_target_type_in_instance.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Comments

StatusFileSize
new21.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 :)

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.

> 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.

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

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

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

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.

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..

> 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.

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. ;)

> 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.

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.

> 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.

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

Updating title.

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...

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?

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.

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.

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.

Status:Needs work» Needs review

Status:Needs review» Needs work

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