Needs review
Project:
Views Fusion
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Jun 2008 at 12:19 UTC
Updated:
26 Oct 2008 at 08:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
folkertdv commentedSomehow the attachment didn't get sent along.
Comment #2
folkertdv commentedThe problem seems to extend a bit further than what I anticipated.
When more than two instances of the same join are used, there were still unique table errors.
I came to the conclusion that array_merge did not merge the query arrays the way they should be merged.
For instance, the query->joins array:
array_merge'd with (notice the different index of the relativity_parent join -- 1 vs 2):
would result in:
While this should have been:
Regarding the query2->tables array:
merged with query1->tables using array_merge:
results in:
while it should result in:
Since the different arrays in the query object are built up in different ways, using simple array_merge will mess things up quite a bunch.
The code I'v used to fix all my problems (this is not really patch-worthy in its current form) is as follows:
Would like to hear your thoughts on this.
Comment #3
folkertdv commentedAlso, in views_fusion_views_merge there's a missing line:
which caused my exposed filters to assume values of other (non-exposed) filters. Simply because the filter array was missing a bunch of values.
Comment #4
behindthepage commentedGood work Folkert,
That solved the "not unique" error
I still had problems with "unknown column" SQL error message when I had both parent-child and child-parent fusions which I tracked down to incorrect table and column names.
I have fixed this in the following patch. The patch also includes Folkarts code.
i must confess the code of this module is a bit complex for me to understand fully so I may be missing something simple but my code fixes the problem.
Regards
Geoff