Proposed relationship API with real live code

I have a 10-line .module file that does nothing but wrap an 'include' around this; the idea was to release it as a 5.0 module, and lobby for just the .inc to be included in core. Thus the extremely lightweight nature of it...

I'm not sure views_bookmark would make sense for it, as that's more of a 'marking' tool than a 'relationships between nodes' module. Things like book.module, casetracker.module, nodereference.module, and so on are all examples of what might make more sense to port to it. Hmmm. Hacking book.module to use this, and calling it 'outline.module' as a demo, might be a nice example. Hmmmmm hmmm hmmm.

I'll try to think of a name for it that doesn't conflict with an already existing contrib module, and release it for Drupal 5 this evening.

Nice. I agree that a common storage engine for node relationships is a good thing. However, how would one build efficient recursive relationships with get/set functions? For instance, take the comment tree. It would get very SQL-expensive to stick with the get/set functions.

Indeed -- I'd suggest those would be good candidates for specialized optimized tree selection functions.

I think performance over a large number of nodes (eg, displaying graphs of nodes, possibly in Views possibly not) would be the main bottleneck for any simplified relationship API.

Here's a sneaky bit. Because we can store more than just a single kind of relationship, we can do a lot of creative things. For example, one might consider storing a relationship for a leaf back to each branch in the tree it's part of, all the way to the trunk node. That would allow single-query lookups of the entire parent tree for a node. The 'weight' flag could be used to indicate the depth of each individual relationship.

And very data intensive kinds of relationships could be moved off to separate tables as needed.

so, I think its important not just that two things are related, but also to label what type of relation it is

That's what the 'relationship_type' field is for; when relating a person and a car, as in your example, you could put 'mechanic' in that field.

Node-centric. This is a big, big issue - a relationship API definitely needs to be able to relate users. Comments, attachments and taxonomy would be a plus too!

Indeed. Everybody's made that point so far and I yield. ;-) Making everything in Drupal a node is a good thing, IMO, but a separate issue from the relationships question. It should be done, and robert has suggested a relatively small addition to this API that would make it possible.

Extensible back-end architecture. ... The regular object-relationship-object columns will be useful for quite a few things, but is difficult to apply multi-level queries to and simply won't scale on big sites. Since we won't get these into core, we need to be able to abstract out the 'storage engine'.

I'd definitely be interested in this, though it already supports specifying alternate tables which could contain their own additional columns, but I'm pretty sure that's not what you mean. My question, though, is this: why would a system of the complexity you are describing even need to go through this API? Couldn't it simply do its own thing?

The purpose of this API is to simplify something that comes up over, over, over, over in Drupal: linking arbitrary stuff together, building simple trees, and so on.

To get beyond that we need to start doing selective denormalization, SQL tree mappings or external tools such as the Arc RDF store. These work great - but don't always cross use-cases very well. For example, SQL tree mappings are great for hierarchical relationships, but are difficult to use for non-hierarchical network relationships.

That sounds interesting. Would it be possible to create a relationship_tree table, for example, that includes one extra field, the flattened hierarchy? Or perhaps the 'alternate table' approach I've outlined is insufficient.

when whipping this up, I decided explicitly to avoid many of the high-end features. An earlier version of this code did allow for some of the stuff you describe -- storing relationship definitions, defining inverse and synonymous relationship types, etc. But in the end it added a LOT of cruft and gained very little; implementing crazy stuff like RDF on top of it would still take tons of additional code, and the simple cases (adding buddies, bookmarking nodes, definig book hierarchies) didn't benefit. We've spent years kicking around talk about the need for a simple relationships API in drupal, and it seems like things always stall around the relatively esoteric big picture features. Why not implement the 'simple' cases? It's an improvement over what we have today, and doesn't block anyone from implementing something more complex.

I'm open to anything that makes the esoteric and specialized stuff possible, I'm just kind of skeptical after ~2 years of making noise on relationship apis. I've heard and seen lots of huge plans for all-encompasing metadata frameworks... After all that time, the best general use tool we have to connect things together is still CCK's nodereference field.

I spent this weekend beginning to tackle comments-as-nodes, and used this relationship API as a starting point. I'm beginning to realize that you're right: different applications of the relationship API will want to tag different meta-data onto their linking records.

Because of the relative simplicity of the API right now (get and set are relatively straightforward) I think I'd like to release this as a module for Drupal 4.7 and 5.0. Once there's some feedback in place, I'd like to look at the kind of stuff you're talking about: pluggable backends and ways of capturing more meta-data for each relationship record, and the flexibility to relate anything-to-anything. 'node' could serve as a default for both the source and target, but could be changed to anything else.

It's times like this that I wonder whether a keyed array would make a better parameter for something like this. I know that it was unpopular with node_load(), but it seems like it could really help here, where there's a long list of optional parameters that can interact in different ways.

for example:

Any thoughts?

The terminology you need is Domain and Range.
as defined by RDF Syntax etc

I supported this with my relationship efforts - just to make the UI more intuative - but managing THEM looks complicated.

.dan.