# Summary

Relation is an API module and storage model for both simple and the most complex relations between entities. The module can handle both directional and symmetrical relations very well.

Relations are entities and can therefore have fields. This makes Relation the most flexible and powerful relation model out there. (Still, using Relation with anything but the default SQL storage will not work in most cases.)

There is a 8.x-1.x-dev development releases for the module for D8.

# Project URL

https://www.drupal.org/project/relation

# Where is the code?

https://www.drupal.org/project/relation

# Estimated completion date

Unknown

# Dependencies

None

# Who's doing the port?

Looking for a new co-maintainer to finalize the port & maintain D8 version of Relation.

# What help do they need?

Unknown

# D8 roadmap

#1988922: Relation for Drupal 8 Development
#1932170: Status of Drupal 8 version of Relation

# Background and reference information

Unknown

Comments

legaudinier created an issue. See original summary.

mmjvb’s picture

Status: Needs review » Needs work

With a dev release Status should be Needs work

mikran’s picture

A new co-maintainer is needed for the D8 port of the Relation module.

That being said there is much less need for the module in D8.

I will continue to use&maintain the D7 version.

mikran’s picture

Issue summary: View changes
Joel MMCC’s picture

Why is there much less need in D8? Does D8 already have some sort of fieldable relations in core? I know that D8 has Entity Reference in core, but is it fieldable? Does it do cardinalities other than two? Transitive?

mikran’s picture

For complex cases there is dynamic_entity_reference that basically makes any entity type fieldable relation. There is much less need for relations to be of relation entity type now that entity API in core is so much better.

dqd’s picture

...that basically makes any entity type fieldable relation

This part is misleading. "A fieldable relation" is a wide phrase .... This is not the intension of DER, at least, as posted on project page. The main reason why users still take a look at D8 port of relation is the "Uncoupled Drupal movement" and the wish to be able to build more complex content relations build in admin UI, connected to the same questions like for years: what if I would like to control relations and their siblings in a tree or if they are sub-related, if they are unique and/or if they should be in a tree with others having the same main A connection, etc ... DER can't provide this OTB. And as of now, referencing in D8 is very limited. It is more like "mentioning" another content without any more options to build content structure on this.

nevergone’s picture

This port is abandoned?

Joel MMCC’s picture

To provide an example showing why fieldable relations may be desirable for various use cases, imagine an organization of musicians that includes multiple musicians, multiple musical disciplines (performer, arranger, composer, director, etc.), multiple sub-types of performer (various instruments, various voice parts of singing, various other types of performance such as interpretive dance), and multiple musical organizations (performing groups, etc.).

Now let’s say that a certain individual is a member of multiple performing groups (organizations). In one (say, a Barbershop Quartet) he sings Tenor Vocal. In another (say, a Dixieland Jazz Band) he plays Trombone. The Dixieland Jazz Band never uses vocals, and the Barbershop Quartet never uses instruments of any kind (except a pitch pipe for initial tuning).

The relation of Musician↔Organization needs to account for this. The Tenor Vocal and playing Trombone would be entries in the sub-type of Performer, stored in a Performer Types entity. So we need to relate to that as well. But if we relate the Musician to that, then we know that the musician is a Tenor and a Trombonist, but not which he does in which organization. If we relate it to the Organization then we know that the organization has at least one Tenor or at least one Trombonist but not who it is.

The most effective way I know of to resolve this is to have the Performance Type reference be a field on the Relation entity itself that relates the Musician to the Organization. That way we know that he sings Tenor in a Barbershop Quartet and plays Trombone in a Dixieland Jazz Band. Without that, it looks like he sings Tenor in the Dixieland Jazz Band as well as in the Barbershop Quartet, and plays Trombine in the Barbershop Quartet as well as in the Dixieland Jazz Band — and that’s just wrong!