Duplicate of Entity Reference Field module?

Subscribe.

.

EntityReference has one thing ref_field doesn't have - Views relationships.

That said, these modules need to merge, and it might be worthwhile merging them both into References.

Entity API is practically assumed to be a dependency if you're even touching entities. Of course, since this is just a field, it might be avoidable, but I wouldn't worry much about that. It's a module that a Drupal install needs and has in any case (VBO, Rules, Commerce, Organic Groups, need I continue?).

And yeah, I only found out about ref_field yesterday myself. Merging efforts is needed. Not sure about how the code compares though.

/me subscribing thinking of the Relation module and that we probably should join forces somehow...

@dixon_
This is a reference field. Whole different story from Relation.

Well, Relation is very soon bundled with a "simple" field too, which makes it behave exactly as a simple reference field.

What if we would have used something else than Views, for simple lists? :) We don't. Joining forces is always the best and creates the most flexible and reusable solutions.

We built this module for a project on which we *also* use Relation. This module is designed specifically for the 1-n types of relationships, that the Relation module is completely unable to handle.

I see a possibility to join forces in that Relation could depend on entityreference for its endpoint field, that is currently pretty much locked down.

*interesting*

tell me about how Relation is completely unable to handle 1-n.

chx: I have not tested Relation, but using an entire additional entity structure for what can be a simple *reference* structure is a bit OTT.

IMHO what we should strive to do is:

• Combine all of the separate reference modules (references, ref_field, entityreference) into one, i.e. the References module.
• Maybe provide a migration script / tool to give people a way to upgrade a Reference field to a Relation field.

Personally I have a project that would be able to make great use of the Relation module, but most of my use cases are better off without the associated overhead and work just fine with reference-style modules.

UI is being adjusted to be theoretically incorrect but more in line with what people who don't understand anything #1175386: Provide widgets for specific entity types, 1:N is being fixed #1248916: [re|ab]use nonbinary directional relations for 1:n. We could work together instead of confusing everyone.

Subscribing...

I've looked into ref_field, and EntityReference is clearly better, and has more features.
I found numerous nitpicks in ref_field (db_select instead of EFQ, no usage of entity_label, more confusing code in general).

Also, we don't need to depend on Entity API. Only a single formatter does, so we can just wrap that one in a module_exists().

I want to relate/reference fields, blocks, and views. There's already modules for this, but if it could be kept in mind, so we can get people doing things in a consistent way, that would be fantastic.

@danielb
Can you link to the module you are talking about? Cheers

Views
http://drupal.org/project/viewreference
http://drupal.org/project/viewfield

Blocks
http://drupal.org/project/blockreference

Fields
http://drupal.org/project/fieldreference (abandoned)
http://drupal.org/project/peekaboo (references field only within current node, plus adds ajax to load/reveal the value - needs a rethink)

Neither blocks nor views are entities. So I see no point in mentioning them in a discussion about different solutions for referencing and relating entities.

Subscribing. Which module will stay here and which is merged to other in future, Entity Reference or Entity Reference Field?

Entity Reference is definitely not going away.

"Entity Reference Fields" module has an optional synchronize feature for auto back-referencing.

Now *that* is stupid! If you need backreferencing then you use relation , that's why it *exists*.

chx - your comment is bemusing... It’s like me saying using Entity Reference is stupid since *that’s* what Relation is meant for. There are 3 modules mentioned doing 'similar' stuff here - pick one that works for you.

Backreferencing (syncing) was a feature request on Entity Reference Fields, so it wasn’t *that* stupid... Plus, I personally prefer the setup of ERF over Relation for some site work: the autocomplete and syncing is nice in ERF, whereas you need the Relation 'dropzone' block for setting up relationships on Relation with pick pick etc.

Cheers.

Neither blocks nor views are entities. So I see no point in mentioning them in a discussion

People want to reference things other than what is currently handled by the Entity API. Better to bring it up now and start planning for the future. If you're going to consolidate a references module, these are things to consider. Whether anything is done about it now is another story.

(Links unrelated)
#430886: Make all blocks fieldable entities
What else should be entities in Drupal 8?

@danielb
What I meant is mentioning them in "this" discussion, since this module won't be referencing anything other than entities, and we are talking about unifying "entity" referencing.

#26 that's not true any more. There's a widget now for creating relations. It needs some polish for sure but it's there.

@chx - I have tested the widget but was making reference by the old 'dropzone' name (the Relation Entity Collector block) where you have to pick using a block. Therefore, my comment stands on the usability aspect and people should check out the different module referencing methods to see which best fits their needs/complexity for a relation setup.

Happy to assist Relation module for widget testing.

A bit of clarity on the "stupid" comment: Relation is designed from the storage model up, rather than from the UI down. Each relation is a set of n rows in a DB table, any you can just as easily look the same relation up from any end point. This is extremely efficient relative to back-referencing on a reference style module, unless there is some back-reference storage as well (in which case it's still reasonably efficient). Since relations are separate entities, you can get the back-referencing working without needing fields on any of the entities involved (eg. with views), and, if you chose to use the dummy field, you can add it to the entities after any relations are created, and they will still show. The dummy field is basically just a front-end that displays relation data without storing any data in the field.

If your project is going to be relying on back-references a lot, I would definitely consider using relation (at least, once it's stable), but there are definitely going to be cases where it's overkill, and where a references style module is better (BTW, if anyone can think of a couple of good examples, it might be worth putting them on the relation.module page).

Re: 1->n relations (assuming people mean directional, as relation clearly already handles n-ary symmetric relationships), actually, relation already handles 1->n relationships by default (the first entity stored is assumed to be the "source" - the 1 in the 1->n). It's just the UI that's limiting it at the moment. It's even possible that we might store n-m relations in the future, but some discussion will have to be had before that happens.

#12 morningtime: I thing you're misunderstanding the concept of arity. if you want 1->n relations, then your arity will be 1+n, not n. minimum arity is irrelevant (you can't have a relation/reference with only one participant, that's an attribute). The current problem with the UI is that max arity is limited to 2 at the moment.

Subscribe.

sub

ref_field now has text on the project page recommending that people use Entityreference instead. Case closed.

@danielb
What I meant is mentioning them in "this" discussion, since this module won't be referencing anything other than entities, and we are talking about unifying "entity" referencing.

uhh.. so was I