Ok, after some discussion with sun, I'm wrapping my head around this slowly. There may be mistakes in what I write here:

So, what we have is a system for creating basic relationships between entities. What we need is a way for users to create arbitrary bundles that have at least a predicate/name, and a specified set of possible object/target entity types(1). Next we need a UI for adding fields to those bundles(2).

We don't really need to worry about n->1 relationships, as they are covered by Field API -- just duplicate the field on what ever entity you want as a subject/source.

A couple of points for discussion:
- Is there any reason to limit the possibilities for subject/object in the module, or is it fine to leave all options open to the user (could they break anything?)
- Should the settings for the predicate and object set be in the field settings, or in the field instance settings? I don't know enough about this yet, but might there be trouble with things like views if we go with field instance settings, and the field is re-used on different entities with different settings?
- What for a UI? Should we code our own, or should we use entity.module?

What have I missed?

(1) This covers #963360: UI for limited references of specific entity types
(2) This covers #948946: N-ary relationships?

CommentFileSizeAuthor
#12 relation-HEAD.bundle.12.patch2.79 KBsun
#11 relation-HEAD.bundle.10.patch2.98 KBsun
#9 relation-HEAD.bundle.9.patch1.99 KBsun
#8 relation.gif7.49 KBsun
#4 relation-HEAD.entity-bundle.4.patch1.58 KBsun
#3 relation-HEAD.entity-bundles.3.patch1.09 KBsun

Comments

naught101’s picture

naught101 commented

Also, I'm not entirely sure how this works with the $entities['relation']['bundle'] array in relation_entity_info(). Is there another way of making drupal aware that these custom bundles belong to the relationship entity?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

The 'bundles' key is normally populated dynamically. For example, see end of http://api.drupal.org/api/drupal/modules--node--node.module/function/nod...

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Needs review
StatusFileSize
new relation-HEAD.entity-bundles.3.patch1.09 KB

Requires the patch in #981990: Fall back for entities that don't explicitly define an access callback for Entity API

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new relation-HEAD.entity-bundle.4.patch1.58 KB

Additionally taking the WTF in #977380: Entity bundles as entities is confusing into account.

naught101’s picture

naught101 commented

So, looks like we're gonna need a 'relation_type' table similar to the node_type table.

How's this for a minimum set of requirements?

type:
Entity type name (machine name)
name:
Human-readable name
predicate:
(do all relations need a predicate? This is useful as well as name, eg. For RDF predicates that aren’t semantically “nice”)
nary:
Flag whether a relation is n-ary, binary (subject:predicate:object), or unary (attributes)
description:
description (maybe not neccesary?)
module:
Module that defines this relation type

I figure everything else can just be a field. If the predicate isn't always necessary, it could probably be a field too.

I wonder if RDF linkage (namespaces etc.) would require anything, or would that just be done with another field and in the formatter? I guess that depends on how integrated we want this to be with RDF
(see #981150: Tie to RDF module integration hooks?)

chx’s picture

chx commented

We use an example of company donates to a party and user donates to a party.

  1. The relation when used as a field, has a field_name . This is the bundle.
  2. Then the relation can be used as an entity to attach fields to. This needs a field UI screen much like user or node.
  3. The relation field can be attached to many entity types. On each entity type, which entity type can it relate it to is an instance setting. Ie the donate field is attached to company, user and party entity types. On the company entity type, it allows relating to party. On the user entity type, it allows relating to party. On the party entity type, it allows relating to company and user. (Note that we need to allow self relating like nodereference on a node)
  4. The previous point is enforced by field validate
  5. The relation widget reads the instance settings, provides a select box with those entity types and after picking the entity type shows the autocomplete field for the entity type. (if that's not known, we can ask the user somewhere)
  6. Directed relations are not a problem. If you do not want the party nodes to show the donations, simply do not attach there. It will be an undirected relationship none the less. That's about it...

Finally, we are aware that this needs to be per bundle and not per entity type but there is no bundle registry so we punt on that.

dmitrig01’s picture

dmitrig01 commented

you could (potentially) have trinary relationships too, just can't think of any that aren't better represented by 2 binary relationships :-P

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new relation.gif7.49 KB

relation.gif

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new relation-HEAD.bundle.9.patch1.99 KB

Updated to be based on fields instead.

naught101’s picture

naught101 commented

@dmitrig01: #948946: N-ary relationships? :D

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new relation-HEAD.bundle.10.patch2.98 KB

Fields being relation entity bundles + Entity UI integration.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new relation-HEAD.bundle.12.patch2.79 KB

Alright, more like this. Not sure why Entity API isn't taking over the relation_type entity loading.

chx’s picture

chx commented

I am neither getting your drawing nor your code. Why did we gain a new relation_type entity? Which is not fieldable? What's going on? I do not get this. We want fields on the relations themselves, ie. that's our fieldable entity type. What's this relation_type? What purpose does it serve?

Edit: using companies, users and parties help a lot in explaining I think :) So we have a relation type field with a field_name of donation attached to the company, the user and the party entity types. We have an "amount" integer field attached to the bundle called donation and the entity type is relation. Do not see the need for relation_type anywhere.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs review » Postponed

Postponing this issue for now. Actually, it probably won't fix due to our conclusions of today: http://drupal.org/node/981364#comment-3778106

But anyway, not 100% confident with closing this down yet (due to fieldable fields modules confusion), so keeping it open/postponed for now.

Shadlington’s picture

Shadlington commented
Issue tags: +1.0 blocker

Tagging

naught101’s picture

naught101 commented
Status: Postponed » Fixed

bundle creation has been rebooted. #1113654: Relation reboot

Status: Fixed » Closed (fixed)
Issue tags: -1.0 blocker

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +1.0 blocker

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.