This originates from a discussion between chx, sun, naught101, and dpi and bangpound.
Discussion topic: relation storage, relations-as-entities
Background: relations issue queue
Assumptions and requirements
Assumptions:
- Relations are fundamentally uni-directional. Directionality can be added on top.
- Relations are not editable. If you want to edit a relation, delete it, and re-create it.
Assumptions we discussed but have not shared yet (TBD)
- Will the relationship entity support revisions?
- Will the relationship entity support translation?
Requirements:
- Easy lookup from either end of the relation (and from the relation itself) -> relation index table
Three problems we are facing, quite interlinked
- How do we enter the relation
- How do we display the relation
- How do we store the relation
Answering 1) and 2) pretty much determines 3), but answering 3) does not do squat for 1) and 2), so it makes more sense to answer 1, and 2 first.
Proposal
- Move back to chx's original storage solution - relation index table with two rows per relation, no storage of relation data in fields: (relation_id, entity_id, entity_type, load, ary, predicate) (predicate is related to field_name)
- chx's dropzone solution (see below)
- Keep dummy field. This field instances define which bundles can be part of the relation. The field instance settings define the relation bundle, and default settings for new relations. It also allows us to have formatters (which pull data from relation index table, not field storage), and possibly widgets (which allow us to create data in the relation index table, not field storage).
- Each row in the relation index table contains a "load" flag, describing whether the relation is loaded eg. when the entity is displayed
- We have another table that defines relation entities, and may include things like directionality flag, source, target, anything else we might want to store about the relation. These entities are fieldable.
- This means that we need something like a relation-only EFQ
Dropzone in a block
- block available that catches all entities loaded on the page with hook_entity_load.
- User selects an entity as one end of a relation (or as one member of an n-ary relation).
- User uses normal site navigation (eg. search) to find the other entity that they want, block now includes this in loaded entity list. Does not need a separate page that shows the entity just something that loads the entity.
- User selects this entity as the other end of the relation, and presses "create". Possibly break out to a full page to reorder n-ary relations and select the load flag.
- Relation is created. Because relation data is not stored in fields, entities on either end do not need to be saved.
- This solves the problem of finding entities for the autocomplete.
Our assumption was that we relate to entities that are loaded somewhere on the site.
You load it, we relate to it. That's it. - chx