Posted by robertdouglass on July 1, 2006 at 6:58am
- Standard set of hooks to allow modules to express relationships and query them
- Requirements (based on discussions at OSCMS Vancouver 2006):
- Pluggable frontends (ways of entering and viewing relationships). Experience has shown that there are many different ways relationships can be created and presented to users. See the 'Relationship UI' child page for a simple frontend.
- Pluggable backends (ways of storing/retrieving or deriving relationship data). Experience has shown that some modules will need direct control of the relationship storage space. See the 'Network Relationships', 'Hierachical Relationships' and 'CiviCRM Relationships' child pages for example backends.
- Extensible
- Works with both 1-1 and 1-many relationships
- Object neutral - can relate nodes, users, comments, relationships, URIs
- Can retrieve direct relationships (e.g. friend - L1) as well as as indirect relationships (e.g. friend-of-a-friend - L2, friend-of-a-friend-of-a-friend - L3 etc)
- Can retrieve relationships taking into account direction (e.g. only parents or only children) or ignoring direction (e.g. relatives)
Additional requirements for discussion:
- Each relationship type can be a node - easily extensible with metadata explaining what this relationship 'means'. Additionally - or alternatively - we could allow a simple keyword to define the relationship type.
- Split off the API from the 'standard' backends and frontend to make it easier to maintain and add to core.
- Direct (L1) relationships could be cached with the node - we could even 'grow' the node relationship cache for higher level relationships as they are requested, possibly with certain limits.
- Relationships can be directional or non-directional - we could track this with the relationship type (i.e. if the relationship type has an 'inverse' then it is directional).
- Potential use cases for relationships in Drupal
- Node authorship (multiple authors!)
- Taxonomy (which is relating to a point in a taxonomy tree, which can also be created using relationships)
- Media or other attachments to a node
- Web Links (relating to an external URI) - these could optionally be picked up from the node body and/or tracked using weblinks.module
- Event and volunteer signups
- Comment threading
- Metadata in general
- Tracking users buddies
- Tracking user content likes/dislikes
- Adding AI-like capabilities 'If you liked this, you'll love...'
- Lastly, but certainly not least - the semantic web (RDF, FOAF...) revolution!
- Potential DEP Dependencies:
- Users, comments, taxonomy terms and attachments become nodes. Without this DEP the RAPI would be significantly more complex, because of the need for either a table mapping 'object-ids' to node, comment and user ids, or tracking the tables in question directly with each relationship
Comments
The Drupal.org version
http://drupal.org/node/61136
Just an update
In line with the first 7 points, I've illustrated the relationships module in a big diagram
Everything but the extended logic (FOAF etc) is implimented. I did code in inheiritance, and transitive relationships in the first version, but then found that some of the cooler datastores could do it better than me, so the only logic I support is Subclasses and Inverses.
That layer can be extended either by the datastore layer or the datastore itself.
Relationships are NOT nodes, they are directional statements - triples. The predicate is a keyword, actually an RDF URI, that explicitly states the meaning of the relationship.
I've already made three custom 'plugin' modules that provide their own terms and renderings of data stored as relationships. Touching only the API on one side and Drupal hooks on the other.
Issues
- Scaling :( Some parts of this may get to be very inefficient.
In the 4.6 version I got tied up into prematurely optimizing, overloading SQL queries and caching everything, leading to some bad code. I've scraped out all the query caching confusion again, in order to clean up the flow, and pending some performance benchmarking to find where the time is really going.
Once I start finding bottlenecks, I'll revisit that. I forsee the caching living in the datastore, not the core.
Yes, the module it was sorta broken at various times, but only because it took me ages to get up to speed with Forms API. ... and I was out of the country for a while.
It's now ready to try under 4.7. Although there may still be a few functions that don't work anymore due to 4.7 changes. I've only been testing the stuff I know works :-B
.dan.
I'm commiting this late at night, so I've probably left some crappy debug code in there somewhere
Hi all, Is another potential
Hi all,
Is another potential use case node access? It would probably require changes in core, but is the idea conceivable that you can cascade node access based on how a node is related to another?
Take http://drupal.org/node/61089 for example. In core functionality, this could be compared to book nodes, and their parent-child existence. Moshe made a module privacy_book http://cvs.drupal.org/viewcvs/drupal/contributions/modules/privacy_book/ to choose whether to cascade node access permissions down to child nodes of a parent node. Is doing node access via relationships at all more helpful than the current node access system? Maybe relationships really would be able to play off the existing node access system to make access cascading based on relations possible.
Just some thoughts on use cases,
Ian