Languages

Drupal has some (entity) relationship issues

With entities Drupal took a huge step forward in providing conceptual clarity in how it deals with things like users, comments, taxonomy terms and nodes.

I believe there is one more step to take to bring even more clarity that will hopefully be possible in Drupal 8. This is the content of my Core Developer Summit lightning talk- hopefully it is not completely off the mark.

With entities Drupal took a huge step forward in providing conceptual clarity in how it deals with things like users, comments, taxonomy terms and nodes.

I believe there is one more step to take to bring even more clarity that will hopefully be possible in Drupal 8 (or 9!). This is the content of my Core Developer Summit lightning talk- hopefully it is not completely off the mark.

It goes something like this:

Entities have abstracted (at least conceptually if not completely at the code level) the task of dealing (loading, reading, querying) with things that you can attach fields to. Drupal is now a composition of these Entities into an architecture that creates a content management system with users, nodes for content, comment, tags, etc. This architecture describes the relationships between entities and their implications.

However this architecture is not transparent. It is spread all over the code. It is Drupal. You cannot change it in an architecturally clean way.

I think we are a step away of being able to not just have one Drupal but many Drupals. What is takes is to make explicit the relationships between entities.

What are relationships?

Consider this:

Entity A is a comment to Entity B
A comment relationship is when a Main Entity is discussed by a Secondary Entity and it is displayed either below or in an associated page to the Main Entity

Entity A is a taxonomy term to Entity B
A taxonomy term relationship is when a Main entity is annotated by a Secondary entity and is (typically) displayed below the Main entity

Entity A is following Entity B
following is when one Entity is notified of activities performed by/to another Entity

Entity A is a friend with Entity B
Friend relationships are when both Entities are notified of activities performed by each one

So relationships are just what meaning we decide to give a certain word like comment, taxonomy term, follows, friends together with some logic about what to do when the relationship exists and how to represent it.

If we actually represent this in code by having an explicit Relationship concept with it's associate type and logic building Drupal website then becomes:

1. Define entities
2. Define relationships between entities
3. Build views

This is much better than the situation today where we have content types with some fixed relationships to things like comments and terms but then we also have nodereference and userreference in order to build out other relationships to users and / or other nodes.

It all comes under one conceptual roof and changes the nature of what Drupal is. Drupal is the system that manages all of this and can re-create Drupal as we know it today with nodes, terms, etc but it can also do other Drupals. It makes the architecture of the CMS clear and separate from the other stuff and this means that we can then manipulate it.

A note: this is not about what the end user sees. They don't need to know anything about this. This may not even be about what your everyday developer / site builder sees either as they may well only ever be at the level of a specific entity + relationships architecture.

This is for the people that really get into the bowels of what makes Drupal Drupal and should give them a change to change that.

Another note: This is here so that it is discussed - it is not fully thought out yet. The main point is - should we make the relationships between entities explicit? And if we do that would that provide us with significant expressive power to do more?

This attached PDF says all this in slide form.

Comments

Submitted by bangpound (not verified) on

Drupal 7 is the time for this to be hashed out in the contrib laboratory. I also spoke about this very topic at the DCSF Core Developer Summit. See https://docs.google.com/present/view?id=dd5cppm9_107hnqrxwdq The title is a bit sensational, but it points to the need to stop constraining the relationship data storage by the type of entity it's pointing to. I kinda also want to see terms go away and focus taxonomy module on vocabulary authoring and relationship modeling for all content.

There are other tasks that I have in mind that will let us dislodge some old-fashioned stuff in Drupal. In particular, we need to replace the parent term field in Taxonomy module with a modern Field API field.

I also want Drupal to be agnostic about relationships among local data entities and remote data entities.

Check out Awesome Relationship module (chx linked it above). See the README file for some of our concepts behind it. If you have ideas, please contribute! I think we are on the same wavelength about this.

Submitted by Anonymous (not verified) on

I like in principle where this leads. However, I think this kind of change needs to start from the underlying data store (or, in other words, no abstraction layer is powerful enough to compensate for the impedance mismatch). I will keep watching with interest.

Submitted by Anonymous (not verified) on

Thank goodness this is finally happening, it's sure taken long enough

Submitted by Anonymous (not verified) on

How does this compare to the ZODB (Zope Object Database)?

What you describe leads directly to RDF tuples. The concepts have been there forever. The performance has never been there. That's always been the problem. :-)

Larry - what I described is implementation agnostic (I don't go much further than talk about fields and NOT entities) - performance is part of the reason (although I haven't worked out all the implications) the other part is conceptual clarity. The AwesomeRelationships approach goes the Relationship is an entity route and it will be interesting to see how far that can take things

Submitted by Jason Zhang (not verified) on

My post is probably going to seem incredibly belated and/or ignorant, but here you go:

I've recently started developing modules that depend on knowledge of relationships between Drupal entities. Without overly convoluting this thread, part of the functionality basically involves building a layer that directly sits on the Drupal data infrastructure and syncs its own (augmented) model with the Drupal base data plus additional data injected through the specific application layer.

The module initially constructs an entity graph (with relationships), and then updates it as triggered by entity CRUD (well, possibly not "read"). Whatever functionality relying on specific paths in this graph looks up *relevant* nodes (as in the graph) and operates on them. This mechanism limits the impact of cascaded updates to only targeted entities. The only caveat is that there is currently no standard good way of cascading entity deletion and triggered actions without running into race conditions. The graph can be locally updated, but dependent applications cannot reliably determine whether certain paths in the graph have disappeared or never existed, or whether existing paths are about to be removed, due to module weights and subsequently the hook system. (Updates generally don't have this problem because forward link updates, e.g. term selection changes, are in a separate part of the pipeline from that of backward chaining dependent entities on update, which is where modules commonly observe updates so they can update themselves.)

On another note, there is also this project:

http://drupal.org/project/entity

If sufficient modules get on board with the Entity Metadata API to model relationships and the API itself contains hook invocations specifically placed at key points in the relationship to transparently notify entity updates (and backward chaining them), the CRUD-triggered change aspect will be complete. Modules building on this layer can then make transitive inferences (or for that matter any other kind of inference) and then optionally cache them. This could potentially get around the performance issue.

Submitted by stop snoring (not verified) on

It’s actually a great and helpful piece of info. I am glad that you shared this useful info with us. Please keep us up to date like this. Thanks for sharing.

Submitted by LateLekly (not verified) on

I think this is among the most significant information for me. And i'm glad reading your article. But should remark on some general things, The site style is perfect, the articles is really great : D. Good job, cheers

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
By submitting this form, you accept the Mollom privacy policy.