Hi - had a good look at the module - awesome stuff I think. Just one question - I really don't like the concept of relaitonships being a type of Entity but I understand that making it an entity allows it to hook into various useful "stuff" that are already there.
How set are you on this approach. I see two alternatives:
1. A special kind of field that alongside its storage, widget and formatter comes with some relationships logic (perhaps some actions)
2. A completely separate concept to both entities and fields.
It really is just a question of conceptual clarity - subject and object are one type of thing - verb is different.
Comments
Comment #1
Anonymous (not verified) commentedI'm passing this to chx. He made the case for this to me at Drupalcon SF. The reasoning behind relationship entities should be documented. You are correct though that it's a practical view of what's possible with entities in Drupal 7, particularly custom entity controller classes.
Comment #2
naught101 commentedSubscribing.
Here's one good reason why relationships as entities might be useful: #948946: N-ary relationships?
Comment #3
sunComment #4
ginc commentedwhat is the decision we have to make here?
Comment #5
Shadlington commentedTagging
Comment #6
rlmumfordAre relationships entities, fields or something else? I'm erring towards something else... It seems more conceptually accurate.
Entities were defined http://drupal.org/node/460320 as "loadable thingy, that can optionally be field able". I don't see why a relationship would be loadable or field able. I can't think of any uses.
Actually, maybe I can, you might want to flag relationships - but that's it.
Comment #7
Shadlington commentedI can see why you would want them to be fieldable - for attaching additional information to the relationship.
I good example I saw given in another issue is of a relationship entity used to define donations.
The relationship is between donaters and donatees and there is a key additional field of the amount being donated.
This could actually be a more generic financial transaction entity with an additional field (or fields?) defining the nature of/reason for the transaction - in this case 'donation'.
Comment #8
rlmumfordBut (and at the risk of repeating what was said there) the Donation would (should) be a seperate entity with two relationships - one being who it was made aut to and the other who it was made by. In my view relations should be graph edges between vertices (entities) - either directional or not.
Comment #9
rlmumfordUltimately, shouldn't this model (or be able to) the relationship between Nodes and Taxonomy? And Nodes and there author?
Comment #10
ronald_istos commentedI think the problem with this - and my initial issue with it is that there are two different point of view that conflict in terms of terminology.
1. From a conceptual point of view you want to be able to say entities = nodes in an RDF-style graph and relationships = edges, which seems to indicate that you cannot have relationships as entities because they are fundamentally different.
but if we separate Drupal entities from that conceptual mapping and simply say that Drupal entities are a way to store stuff in the database, pull it and and attach stuff to it then:
2. Implementation-wise it is very useful to represent relationships within Drupal as entities because that is the main method we have to store stuff in the database, attach information to it and get it out of the database!
So - for me my initial question is answered. As long as we split the conceptual view of things form the implementation view having relationships saved as entities works because entities in Drupal != to RDF-style nodes - they are just a storage + data manipulation mechanism and we should keep the conceptual view of the problem separate from the implementation so that we don't trip over terminology.
Comment #11
naught101 commentedronald_istos: Absolutely agree, the problem now is whether relation module or some kind of field-group/combofield module should provide the entity. I haven't been keeping up with the discussion, but if the latter is still an option, it'll be being discussed here: #939836: combofield / fieldentity / field-collection / embeddables
Personally, I'm still leaning towards relation.module providing it's own entity. As you say, there's plenty of potential metadata that may be useful to attach to all relation entities, and that's just gonna be a massive pain if we're relying on a third party module for the entity.
Comment #12
naught101 commentedDecided. Relations are entities. They will eventually be fieldable. This is fixed in the reboot thread.
Please see #1059018: Initial release? (Relation) for a beta announcement in the next few days.
Comment #14
sun