The views_many_to_one_helper currently steamrolls over relationships that the handlers it attaches to may be set to use, at least in some cases. I suspect it's probably fine if the join is direct between to the relationship's base table, but if there are intermediary tables, it definitely messes itself up; it attaches itself directly to the base table, rather than the table (alias) specified in the original relationship.

Ick, what an indecipherable mouthful. Well, the attached patch fixes it, at least for the use case I have. Three cheers for views_query::get_table_info() being able to find what it needs even if an alias is supplied!

CommentFileSizeAuthor
many_to_one_helper.patch939 bytessdboyer

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Needs work

This doesn't make sense to me. If you force the left table, what you're doing is saying "We don't care about tables in between, join these two tables directly." I'm not sure how it fixes your problem, but it really seems like if you have a long chain (let's say something like term_node -> term_data) what you could end up doing is joining term_data directly to node. That obviously can't work.

sdboyer’s picture

sdboyer commented

Wow, been a while since I wrote this, so I'm gonna try to work on memory...

If I recall correctly, the only behavior this is actually supposed to change is what happens at the beginning of views_join::join(), where it checks for something in the left table. If the left table isn't explicitly set there to that relationship's alias, then no left_table is ever specified, and we end up in that second case (with no table alias) that doesn't work at all.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs work » Fixed

Ok, figured out the problem here and created a better fix.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.