Merge this module and relation_endpoints

Entityreference is designed specifically for 1-n relationships (ie. one entity relates to one and only one other entity, like the node-author relationship). This is just impossible to guarantee in the Relation schema.

Also, I'm going to add that Relation is more then welcome to depend on Entityreference. After all, relation is nothing more then two or more Entityreference fields attached to a special entity type called Relation.

To #4 I would like to object that Relation has at least four areas of functionality that Entity reference hasn't, at least yet:

1. Relation can manage symmetrical relationships, and for example load all other nodes in a relation when using Views relationships.
2. Relation has the "unique" option, disallowing more than one relation with the same end points.
3. Relation allows combining entities of different types in the same list of end points.
4. Relation has some add-on modules that makes it easy/easier to create new relations (which, in turn, is a benefit from Relation being more standardized than two Entity reference fields attached to an entity type called relation.)

However, it is pretty obvious that there are overlaps between these modules, and I hope that this means synnergies and cooperation rather than teeth-grinding. (I might add that it was me that kind of got this issue started. Maybe I'm sorry about that.)

@Damien: On a semi-related topic – how necessary is Entity API for Entity reference to work? Is it a heavy dependence, or is it a minor convenience?

I'm not opposed to merging the two modules (relation_endpoint and entityreference), somehow, since they're both doing more or less the same thing. Relation and entityreference are clearly different ideas, and the relation module has some features that entityreference can't or won't implement. But it's true that fundamentally, a relation is little more than a custom entity with a bunch of entity reference fields on it.

Relation_endpoints is more than entityreference because it can refer to multiple entity types.

This is the blockage, for me. The relation_endpoint field is slightly more versatile, in that it can point to entities of multiple types. Damien, I know you said that you wouldn't make entityreference fields be able to point to entities of multiple types (#1292402: Allow for an entity reference field to reference multiple entity types). But with the abstraction from nodes to entity in d7 and beyond, it seems that likely that there'll be a lot more content entities (content in the english sense, not in the stupid nodes-are-content drupal sense). That means there'll be plenty of cases where it will be useful to have the option to select entities of various types in the same type. My feeling is that this is more or less inevitable, and that things like EFQ and so forth will have to deal with it at some point. Besides, what's the worst that could happen? Someone sets up a field that can point to multiple entities, so you just allow them to access entity-generic data...

I'm also opposed to merging the two modules. There's nothing freaking wrong with two similar solutions being developed and over time learning from each other, borrowing, and improving.

Just a lot of duplicate effort and in a site I'm working on you end up needing both which seems rather silly.

@Damien: On a semi-related topic – how necessary is Entity API for Entity reference to work? Is it a heavy dependence, or is it a minor convenience?

The hard dependency on Entity API can go away as soon as we move the formatters to a separate submodule. I have been wanting to do that for a while (and at the same type provide move advanced formatters for other pseudo-reference fields likes taxonomy_term_reference and file/image).

Relation_endpoints is more than entityreference because it can refer to multiple entity types.

As already mentioned, this was a base design decision for this module. Mostly everything in Drupal wants you to know the entity type beforehand to do anything useful (Entity API metadata, Tokens, Views integration, Panels Relationship, etc.). In #1340098: Move target bundle to the field instance settings, some people are studying if it would be possible to move the entity type to the instance level.

Supporting any entity type right of the bat is not on the table, as it makes the whole field completely useless. Just see how hard it has been to build the Relation properties, and you should be convinced that Relation should do the same (for those following at home: relation doesn't have one property per endpoint, but one property per entity type referenced by an endpoint).

Supporting any entity type right of the bat is not on the table, as it makes the whole field completely useless. Just see how hard it has been to build the Relation properties, and you should be convinced that Relation should do the same (for those following at home: relation doesn't have one property per endpoint, but one property per entity type referenced by an endpoint).

Exactly!
With entity-generic relations you know quite nothing about the referenced entities what makes using the referenced entity cumbersome. Entities are not just the new nodes - an entity is a very generic concept as it's just *any* data object. That way, a relation to *any* object is very generic and un-specific - thus hard to use.

However, I really like the idea of letting relation make use of entity-references, including making relation endpoints bound to a specific entity-type. That way, I could see the module being very useful and much more straightforward to use.
Moreover, relation could even become the ECK for relation entities (no shared base-table!), while focussing on relations.

Generic solutions are great, as they allow re-using code and potentially come with lots of flexibility. But still, you'll need to make the right assumptions at the right point, so your generic and super-flexible stuff can be easily used to solve specific problems. This is why we need modules that give certain entity-types a certain meaning, and this is why we need to know which kind of data we are relating too.

The only difference is relation lets you pick multiple entity types....you still know which, and can restrict to only allowing one like entity reference. Simple or more...w/e, seems silly.

ad #17: ops, sry for messing with the issue status.

I think the discussion is worth having, even if it started the wrong way.

> Relation_endpoints is more than entityreference because it can refer to multiple entity types.

I'll add one more reason why Entity reference can't point to multiple entity types: Views relationships then become impossible.

(Arguably that could be fixed in Views: the main sticking point AFAICT is that the UI keeps track of which fields to offer you to add to your view based on the 'base' property of relationships. EDIT: though you'd still have all sorts of issues when you tried to add fields on that relationship...)

More generally, I think this module has a place alongside Relation. If you don't need many-to-many relations, if you don't need them to be fieldable, then references is good enough.

and if you don't need built in backreferences ;)

"More generally, I think this module has a place alongside Relation. If you don't need many-to-many relations"

That was indeed my case in a recent project. I intended to use Relation endpoints, but it was just too cumbersome trying to figure out how to use it with Rules, and entityreference did exactly what I needed, since the references were 1 to 1.