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.

Comments

dawehner’s picture

Assigned: Unassigned » dawehner

Assign for myself.

naught101’s picture

Status: Active » Fixed

Hrmm, 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.

itangalo’s picture

Status: Fixed » Active

Re-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)

dawehner’s picture

StatusFileSize
new3.17 KB

Some tracking of code.

Yuri’s picture

Just 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.

Anonymous’s picture

We 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.

itangalo’s picture

kevee: 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. :-/

Anonymous’s picture

StatusFileSize
new3.21 KB

Above 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.

chx’s picture

Status: Active » Postponed (maintainer needs more info)

Since Oct 23 we have 'title' => t('Relation: @relation_type_label (relation -> @right)', $t_arguments), this in relation. What part did I miss, then?

Anonymous’s picture

@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.

chx’s picture

StatusFileSize
new10.83 KB

That'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.
Selection_019.png

Anonymous’s picture

OK, 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)'

chx’s picture

Category: feature » bug
Status: Postponed (maintainer needs more info) » Active

Oh. That's the bug report then: the key is wrong.

itangalo’s picture

Awesome. 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.

dawehner’s picture

Status: Active » Needs review
StatusFileSize
new1.14 KB

Here 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.

dawehner’s picture

Issue tags: +Needs tests

Missing tag

Anonymous’s picture

I 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.

chx’s picture

But 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.

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community

Got it. I have reviewed the patch in #16 and can confirm that the relation -> entity relationships appear as expected.

chx’s picture

Status: Reviewed & tested by the community » Needs work

Observe the needs tests tag.

alanom’s picture

This 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.

solotandem’s picture

Check 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.

tribsel’s picture

Component: Code » API

hm, 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...

adrien.felipe’s picture

Can't get the #16 patch to apply correctly:

File to patch: views/relation.views.inc
patching file views/relation.views.inc
Hunk #1 FAILED at 228.

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?

chx’s picture

Status: Needs work » Closed (duplicate)