Use case:
For quite some time I have been wanting to use Relation for something that is more or less impossible in D6: To attach images to articles with relations, but with varying captions. With Relation, this is finally possible, since I can put the caption on the relation itself.
However, I cannot display both image and caption in a sensible way.
To add both the image (part of the file entity) and the caption (part of the relation entity), I currently need two independent relationships in Views: node --> relation and node --> file. Both these relationships will pick up any results, and the view will display all possible combinations. With just one matching relation this is just fine, but after that it starts to get out of hand. (See http://vimeo.com/28175246 for a quick screencast trying to explain this.)
I see two solutions for this problem:
1) Having a Relation view, using relation to join in the end point entities and putting (contextual) filters on them.
2) Having a new relationship relation --> entity, which would allow the chained relationship node --> relation --> file.
This feature request concerns number two of these.
I don't currently know how to set this relationship up to avoid adding the base object in the view – in the example above corresponding to getting both the file and the node entity.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | 1260252-relationship-right-better-key.patch | 1.14 KB | dawehner |
| #11 | Selection_019.png | 10.83 KB | chx |
| #8 | 1260252-relation-8.patch | 3.21 KB | Anonymous (not verified) |
| #4 | 1260252-relation.patch | 3.17 KB | dawehner |
Comments
Comment #1
dawehnerAssign for myself.
Comment #2
naught101 commentedHrmm, I haven't had any need to try this out, but the demo at London drupalcon (see http://london2011.drupal.org/conference/sessions/relation ) shows a process doing pretty much exactly what you want, so I'm gonna call this fixed. re-open if I'm wrong.
Comment #3
itangalo commentedRe-opening.
The London presentation shows that you can add either relationship entity --> entity or entity --> relation. My problem is that if I add both of them (since I want both entity and relation information), I end up with duplicate rows.
This is demonstrated and somewhat explained here:
* http://vimeo.com/28351684 (Setting up the view, realizing we got dupilcate rows)
* http://vimeo.com/28175246 (A rough explanation as to why we get duplicate rows)
Comment #4
dawehnerSome tracking of code.
Comment #5
Yuri commentedJust for your information: this is not a 'duplicate' issue, but a 'multiplied' one. In the troubled views setup mentioned by Itangalo, if you have set 10 people as friend, the list will contain 10 friends x 10 = 100 items.
Comment #6
Anonymous (not verified) commentedWe have a similar problem, the "multiplied" issue could be resolved if one sets up a view with one relationship between the entity and another entity (like user -> node) and then another relation between entity and relation (user -> relation) that references the prior one with a relationship itself.
Comment #7
itangalo commentedkevee: Well, that would work if you only have one entity relating to the (in this case) user. If you have several, you will get all of them by adding the second relationship. :-/
Comment #8
Anonymous (not verified) commentedAbove patch re-rolled against current 7.x dev.
This relation works until you want to select a field using the relation because it references the relation table for fields rather than the source table. Will do some more work on it.
Comment #9
chx commentedSince Oct 23 we have
'title' => t('Relation: @relation_type_label (relation -> @right)', $t_arguments),this in relation. What part did I miss, then?Comment #10
Anonymous (not verified) commented@chx - agreed, the title change causes a lot of confusion.
The main difference between the Oct 23rd one and the one in this patch is that this one exists only once for each source bundle, and requires a relationship within views to the source relation entity itself to work. It helps get one step closer to solving the "multiplied rows" problem outlined earlier.
Using the "user a is good friends with user b" analogy, when a view listing user A's friends is shown along with the field for "good friend/acquaintance", using a straight user <-> user relationship, followed by a user <-> relation relationship, selecting the friend type field, you'll get duplicates. It makes more sense to have a user <-> relationship relation, which would allow you to get data on user A and the relationship, then a relationship <-> user relation relationship that references the prior one to get data on user B without dupes.
Right now without this patch, if you set up a user view, you can get the user -> relation relationship just fine, but you can't get the corresponding relation -> user relationship.
Comment #11
chx commentedThat's not a title change that's a new feature. I have a user -> relation relationship. This one shows a relation-type view but it equally works with starting from user, going to relation etc.

Comment #12
Anonymous (not verified) commentedOK, I see why I was confused:
The name of the right relationship was
'Relation: @relation_type_label (relation -> @right)', however, the key for the relationship is'relation_base_right_' . $entity_type_right, which would mean if you have multiple relations in your site (I have a project with eight!) it appears that you are missing some relation -> entity relationships. However, that is not the case.Seeing as there can only be a single right-joined relation -> entity relationship per entity type, not per relation type, I suggest changing the title of the relation_base_right_[entity_type] relationship to something like:
'Relation: @relation_type_label (relation -> @right)'Comment #14
chx commentedOh. That's the bug report then: the key is wrong.
Comment #15
itangalo commentedAwesome. I had missed this new feature – looking forward to checking it out and confirming that I can list the desired data in Views without getting extra rows.
Comment #16
dawehnerHere is a small patch which adds the relation-type as part of this key, so this key will be unique enough.
The code above will provide some automatic conversion from the old key to the first relation.
Regardless the users have to be informed about this.
Comment #17
dawehnerMissing tag
Comment #18
Anonymous (not verified) commentedI would just point out that since the left table will always be 'relation' that would mean a lot of these relationships are technically unneeded (hence my suggestion that the title be changed to just relfect that it's a generic relation -> entity relationship that's not tied to a relation type).
I can see, however, how a key change could be a better UI experience for those building relationships in views.
Comment #19
chx commentedBut it's not a generic relation -> entity relationship it IS tied to a specific relation_type, it's in the definition, it's used in the JOIN, it's tied in every way.
Comment #20
Anonymous (not verified) commentedGot it. I have reviewed the patch in #16 and can confirm that the relation -> entity relationships appear as expected.
Comment #21
chx commentedObserve the needs tests tag.
Comment #22
alanom commentedThis is great! After applying these patches plus the patch in #1344306: Use relation_handler_relationship as handler for relation -> node relationship, content views with a entity -> relation relationship and a relation -> entity relationship seem to work perfectly, and for the first time I'm getting the expected results from each relation-using view that I make. Looks like being a massive step forward!
For me, the <-> relationships still listed in Views UI give no results now - I'm assuming they're now deprecated and will be phased out.
Comment #23
solotandem commentedCheck out #1361780: Replace relationship definitions to cover all the bases and so Relation plays well with Views. I believe it will solve the problem addressed in the issue summary.
Comment #24
tribsel commentedhm, i have similar or same problem with duplicated/multiplicated rows when I add both entity --> entity and entity --> relation relationships. I used current dev version...
Comment #25
adrien.felipe commentedCan't get the #16 patch to apply correctly:
Tried with the last dev version and rc2, it must have already been committed I presume.
But as many others, I still have the rows multiplication when 'node <-> node' and 'node -> relation' relationships added simultaneously, as I do need: nid, uuid and rid data..
What is the status of this? Should it work on the dev release? What patches should we apply if not?
Does someone have a patched working version he could share?
Comment #26
chx commented#1462068: Provide a E1!=E2 exclusion option for E->R->E chain