Relation reboot

for anyone else, ignore the patch, and just work off the "reboot" branch.

I added a clear button to the block, cause I didn't want to clear my session :). Should this block appear even when there are no entities loaded? Especially if there's already one entity picked?

on chx's request, adding a settings page, but not properly. This is actually a per-relation-bundle settings page, and we really need to implement that first. The block would then need to be able to select which bundle, I suppose. It's at admin/structure/relation for now, as I imagine that will be the place for adding new bundles, and this can be moved to admin/structure/relation/[bundle]

Also, wtf is the 'creator' bundle for?

Hrm... in the proposal at http://groups.drupal.org/node/135804 we talk about keeping the dummy fields to define which bundles are available at the ends of the relation. We didn't discuss this heaps, and I think we need to, since all this settings crap is bundle-specific (I can't think of any relation settings that would be global - just as there aren't global node settings).

We don't really actually need the dummy fields, and I think it probably makes sense to have a bundle creation UI in the style of content types. I think the dummy fields would still be very valuable for formatters and widgets, and I think we could probably still use them in the way intended to create bundles (as a secondary UI), but all this could be done as a sub-module.

Er... just realised that dummy fields cannot be the only core solution for determining which bundles are targetable by relations - if we did that, we wouldn't be able to reference non-fieldable entities, like files...

edit: And what about entities without bundles (again, files)

I'm guessing the reboot branch isn't ready for non-developers to try out yet.

However, if you could post when you feel that feedback from non-developers would be useful then I (and no doubt, others) would love to help out by providing testing.

Sorry chx, I know you're champing at the bit, but I hate spending hours coding only to realise that it all has to be re-done (this is compounded by the fact that I'm a really slow coder).

Re: n-ary relations: I think there's two distinct cases here:

1. Non-directional "octopus" n-ary relations. This is the "sibling" style relation that can be modelled by (n(n-1)/2) binary relations. These could be represented by a sentence like "John is a sibling of Mary, Beau, Jess, Leslie".
2. Directional, binary, augmented relations. These relations are best modelled by a single binary relation, and then augmenting relations from the relation entity (basically clauses). An example is "Company A donated to Party B, via Bank C", which would be represented by CompanyA->Donation1->PartyB; Donation1->TransactedBy->BankC. (Gramatically, every relation is either subject-verb-object, or relation-clause-clause_object)

I cannot think of an example of why any n-ary directed relation could be better modelled by the n-ary octopus than the augmented relation model. If I'm right, and there is no such case (w3c doesn't mention one), then there is no reason to allow distinct sets of possible target bundles for the octopus relation type. For augmented relations, you are only ever talking about binary relations, and for those relations, we should supply "source" and "target" bundle sets.

For the bundle config page, were you thinking of changing the options available with javascript, depending on what options above were selected? Also, should we be giving relations a machine name?

BTW, I added a list page, only list names, links to edit page. We can add more to this when we get to the field interface. Also changed the predicate in the block to an autocomplete. I don't think we should be creating relation types from here.

terminology proposal:
arity: number of ends of the relation (eg. cardinality)
ary: index of the end of the relation

changed {relation_settings} to {relation_type}, to match node types. Changed "multi" to "arity", and added "label" and "directionality" columns. Methinks we will need two more boolean columns for directionality on the {relation_bundles} table (should this be {relation_type_bundles}? would make more sense to me), one for "source", one for "target".

chx: the relation/%relation page isn't working, and it makes absolutely no sense to me at the moment - you appear to be trying to get object properties of a scalar relation_id... I can't figure out where those properties are supposed to come from...

ary: index of the end of the relation

index, please, just index. Self-descriptive FTW ;)

sun: index is an SQL reserved word. I used r_index.

Big reshuffle of schema.

Settings page is now working, and submitting fine, using states. Perhaps we should change predicate->type, and label->name, like node?

Now on to validation for relation creation, and viewing relations...

Validation is about half way there. Creating directional relations is going to be difficult.
added proper entity info.

I'm having trouble figuring out how to deal with n-ary relations. currently the loaded entity data looks like this:

    [left_entity_type] => node
    [left_entity_id] => 3
    [right_entity_type] => node
    [right_entity_id] => 1

that should be replaced with :

    [entities] => Array
        ( [0] => Array
            (
                [entity_type] => node
                [entity_id] => 1
                [r_index] => 0
            )
        )
....

Not sure if this should be in the buildQuery, or if I should move it. Problem is that the bundle (which contains the arity, which is needed to create the $query) is apparently not available ($ids doesn't seem to contain it, though it looks like it should).
catch suggested it might be better to load the relation_data rows in EntityController::attachLoad, but I don't have any experience with this stuff, so I thought I'd ask first.

So I'm trying to test this module out and provide some feedback. I've checked out the reboot branch from GIT and I've setup a 'relation' under site structure. But I can't seem to be able to add any kind of 'relation field' to my entities and thus test out the new 'browser'.

Is this not how relation works any more?

jdelaune: Correct. You need to go to admin/structure/blocks, and enable the relation block. Then you need to go to admin/structure/relation and create one or more relation types.
Next you need to go to any page that displays one or more entities of any type, and the block will show up. use the autocomplete to select your relation type (yes, we know this needs some work), and "pick" at least two entities, then press "create relation". You'll see a message that links to the entity viewer page, which isn't complete yet.

At the moment, n-ary entity loading is not working, so the entity display page only shows two entities, and no other information. We know there are a lot of bugs and features missing, that's because we've been focussing on the back end first - have a look at the hook_schema implementation in the .install file to see the layout. Basically, the tables are:
"relation_type" - same idea as node_type, stores relation bundles
"relation bundles" - stores the bundles that are available to each relation type (validation not implemented yet).
"relation" - stores the basic information on each relation entity.
"relation_data" stores the "arms" of the relation - ie. the data on which entities are part of the relation. There are at least two rows for every relation.

entity loading complete. I moved it to attachLoad because the buildQuery had no way of separating different rows into differently named fields - ie. load 3 rows, and the second row overwrites the first, and the 3rd overwrites the second. Anyway, it works now. relation entity page also works now.

Patch for transitivity, also removes a few notices.

Coming along. A few more tests to add..

There's a minor validation problem, see: git show 2ec0ca5
If we don't validate in relation_create, then there's no validation for programatically created fields. If we do, then we're validating twice. I guess we could have a 'validated' flag already, but I don't really know what the best solution is for this one..

Great work coming along here... subscribing.

For anyone else, if you're not here to test and comment/provide patches, please subscribe to #1059018: Initial release? (Relation) instead of here, so we can keep this issue relatively clean. I will add notices there when significant progress is made (eg. alpha/beta/final releases).

relation_dummy_field. Oooh yeeaah!

No field data required >:)

Nice I'll check it out later. I tried it the other day but it didn't make much sense making the relations from a block. Hopefully making them from within a field will make the process more intuitive.

But I know you've been concentrating on the foundations which look great.

The field does not create relations, just displays them. Field-based relation creation may come later, but will be difficult. It definitely won't be part of the first alpha.

Ah okay, is there a reason you choose to create relations through a block rather than just an admin screen?

jdelaune: the basic concept is "you load it, we relate it" - it's very difficult to find entites of all types using an auto complete, for example, so we just use hook_entity_load to gather info on all entities loaded on the page, and then list those as options for relation end points. Other UIs will be possible, we'll see what we come up with (or what others come up with)

for details, see http://groups.drupal.org/node/135804

This has been merged into the 7.x-1.x branch. Feel free to post any bugs on the issue queue.

Re: #28, creating relations: see Relation Select -- a field widget for creating & editing relations.