I just installed the relation module to give it a try, and see which database tables it would create.

It seems to me that a mostly equivalent result can be achieved with a custom fieldable entity type + bundle with two entity reference fields: one for the origin, one for the target.
(In fact we don't absolutely need a custom type, but it allows to avoid unnecessary overhead we would get with existing types such as node or taxonomy term)

E.g. for the company / donation / party:
- node type "company".
- node type "party".
- custom entity type bundle "donation".
- single-value entityreference donation -> company.
- single-value entityreference donation -> party.
- any additional fields we want on the "donation" bundle

Or, for symmetric relations, a single entity reference field would be sufficient:
- node type "person".
- custom entity type bundle "friendship".
- 2-value entity reference friendship -> person
- any additional fields we want on the "friendship" bundle.

(I think this "friendship" example is more useful than "siblings")

Depending on the scenario, a "Dynamic entity reference" might be needed instead of a regular "Entity reference" field.
But the question is still the same.

It seems the authors of this module are aware of the structural equivalence.. see #2315599: Consider Dynamic Entity Reference for storage needs.

My question is: Which advantage does the relation module provide, compared to the technical setup described above?

Notes:
- I suppose the same question applies to the D8 version. But so far I only tried it on D7.
- I am aware of #2283807: relation VS entity reference . Relation can not be replaced by a single entity reference field. But this is not the question.

Comments

donquixote created an issue.

donquixote’s picture

donquixote commented

Of course we would need to get a custom entity type from somewhere.
This is something that relation is giving us, no doubt.
But there must be something else.. or not?

mikran’s picture

mikran commented

If your use case can be handled with entityreference then it's almost always better to do so, even if you're using relation for other things in the same installation. It's true that storage is similar with custom entity + dynamic_entity_reference but relation provides the API functions and support for other modules, such as feeds, rules and views. This is something that is not available by default for custom entity type. The "Rationale" section of the module page lists these things too but that section should eventually be rewritten for D8 and new modules. D8 version is far from complete and things might change quite a bit there.

donquixote’s picture

donquixote commented

I should pay more attention to the module page before posting :)

this hypothetical module would not be able to
1. refer different kinds of entities for one endpoint

Ok, don't need to, most of the time.

2. handle symmetrical relations in one API (for eg. a single rule can be fired for both ends of the relationship)

For this case I would use a two-value entityreference field, instead of two single-value fields.
Not sure what this means for rules, though.

3. list siblings with Views

Just create two relations, one using the other...
Or, for symmetric relations, a new relation plugin could be written, to avoid self-referencing.
Probably this is what relation module already does.
But writing it in a way that works for any entityreference field, might be even more useful.

4. support revisions

For this we need an entity type with revision support.. e.g. if we use node as the relation entity, it would work?

feeds

Ok, no idea :) I don't use feeds that much.

------------

An alternative solution could be to provide a bunch of components that can be used in combination with entity reference, or dynamic entity reference, to get the desired relation functionality, but that can also be used standalone.

Such components would be:
- Dedicated entity type, with revisions, but without the overhead of node or taxonomy term.
- Views relation handler.
- Something for rules and feeds?

I am saying this based on my own expectations on fieldable relations. Maybe I am missing important requirements. And I hope it is not too blasphemic :)