Re-use field storage for relation data

The current schema also allows simple descriptors (one to none relationships), eg. the_earth:is_round

The thing I don't understand is that the two rows don't appear to describe the way that the entity relates to the relationship? eg. which is the subject, which is the object? Or is that in a different table?

Because such a schema would be directional, the current one is unidirectional. Same for #1. We do not have any directionality right now. We can add if we want but note it's much easier to add a flag which one is which than creating an unidirectional module once you have a directional (aka nodereference and backreference).

Flags make sense in the relation_data table. I can think of four possible flags: source, target, auxiliary (n-ary relations), and none/self (descriptors eg. node1:isPublished).

Maybe the latter is out of the scope of the project. There is also another possibility: auxiliary values that aren't entities - eg. scalars.

I'm not sure if the latter few should even be in this table, since they're gonna be fields. Is that gonna be a separate table? if not, this table would probably have to get much more complex, right?

I don't understand why the relation table exists? If relation defines bi-directional relationships, and a directional predicate always has a logical opposite, would it make more sense to have the predicates in the relation_data table? That way you could have :

Then again, maybe it's best to leave the predicate in the relationship_type table or what ever it turns out to be called, and just have the reverse-predicate as a field or something. see #981398: Bundle creation and UI

As sun pointed out in skype, the current schema has no way of supporting revisions. I don't think we can just let field API deal with the storage, because that makes the unidirectionality difficult to deal with, right? Maybe we can add a revision id to this table as well? And that would require a revision id in the relationship table as well, right?

1. One column, a relation id
2. You need to attach the relation field to all bundles it relates to
3. When relating to another entity we load the entity, change the field and save it back (entity API)
4. There is an instance setting whether it's "many" or not , indicating whether to load (if you have a million nodes on a term, don't load)
5. If you need to figure out whether entity A and B are related, if both can be loaded, then load entity A and entity B and diff their field values. If one of them is not load then fire a storage engine hook that we will implement for SQL and will do the current join.

We can remove the entity-ness and piggyback on the combofield/multigroup/whatnot http://drupal.org/node/939836

Oh and this solves the bundle discovery problem we had -- you can only relate to bundles the user already attached the relation to.

baby steps.

hook_field_presave() implementation

This just stops the previous patch from breaking on page loads (there's some empty item in there that I don't understand..). Too braindead right now. will pick it up again tomorrow.

a) i think relation_field_is_empty should check for relation_id b) the widget should use #type value not #type hidden

Other possibility, with fielded relations.

            |entity_type  |entity_id  |field_relation_id  |field_entity_type  |field_entity_id
john:       | user        | 13        | 1                 | user              | 22
mary:       | user        | 22        | 1                 | user              | 13
relation1:  | relation    | 1         | 2                 | node              | 10
house:      | node        | 10        | 2                 | relation          | 1
relation1:  | relation    | 1         | 3                 | user              | 31
pietr:      | user        | 31        | 3                 | relation          | 1

This obviously fucks up the relation_id concept a bit, but it wouldn't be hard to add a top level relation id, parent_id perhaps (which would just be = 1 in this example). This shouldn't event be too hard for more than one level of relation hierarchy (which I think should never, ever happen. At least not without some kind of punishment).

with stuff added to schema. Works without hook_load(), but the presave isn't working..

This fixed some stupid mistakes, and definitely puts the field data into the target entity correctly, but it's not saved to {field_data_[field_name]}.

Do we need to do something more than just save it? Trigger field storage somehow?

This, combined with the workaround at #988780: Merge both modules into one causes an infinite loop
[entity1]_save() -> hook_field_presave() -> [entity2] -> hook_field_presave() -> [entity1] -> etc.

my loop check doesn't work, I guess because it never actually saves either entity. So we might need to pass a recursion depth flag, but I'm not sure where.

Huh. A recursion-depth flag won't work, because if you have other relations attached to the target, they will recurse (separately) on save, so there's still a potential for very large loops. possibly infinite, not sure.

ok, this works. set $target->recursion, and then just don't do anything if that's set in $entity next time around.

works for nodes, but apparently not for users... hrm..

fix a couple of mistakes things, make code more self documenting.

Pretty sure user_save() doesn't accept $user objects with programatically added fields. this may be a problem.

works perfectly with taxonomy terms and nodes.

Awesome! Well done guys!

yep, fine for now. we neet to discuss #989264: field columns are VERY confusing as well though

change empty check back to other_entity_id because relation_id is empty, doesn't get filled until presave.

also, add relation_id to $item by reference, otherwise SQL error.

once more without debugging stuff..

fixed: http://drupal.org/cvs?commit=459424

Damn. last patch introduced a bug - last &$item in the for look stays set, and so gets garbled later. Changed the name of a the later variable to $other_item, but perhaps the reference should be unset/not used in the first place?

Fixed. http://drupal.org/cvs?commit=459760

fixed at http://drupal.org/cvs?commit=468756