Proving bug with Deep nested many_many relations

[dhensby]

When adding a filter to a many_many with a shared inheritance, the FROM table is removed and added as a LEFT JOIN which causes a syntax error.

This means $dataList->filter('ManyManyRel.ID', array(1,2)) doesn't work.

[dhensby]

Ok, So I've fixed an issue where the FROM clause was removed from the DataQuery.

There remains a problem with the actual filter due to the collision of the table names and thus the WHERE clause in the query is ambiguous and doesn't filter on the link table (where I feel it should) and instead filters on the joined table (which is a collision with the FROM table).

[dhensby]

@tractorcow I'd like you're thoughts on whether your ORM work will have fixed this problem?

[tractorcow]

I doubt it, I don't think I've tested this specific use case.

[tractorcow]

1) DataObjectTest::testBelongsTo
Couldn't run query: 
INSERT INTO "DataObjectTest_Company" ("Created") VALUES (NOW()) 
Table 'ss_tmpdb2069596.DataObjectTest_Company' doesn't exist

You need to ensure you add any class with TestOnly interface to extraDataObjects variable.

[dhensby]

thanks @tractorcow added that and now looks like the real reason for failing is happening

[tractorcow]

Did you want to fix these tests? :D I think this should be merged soon.

[dhensby]

Ok, the tests aren't broken, it's the core itself.

For some reason the query builder is joining on the wrong column for the link table.

[sminnee]

@dhensby any enthusiasm for remedying whatever is broken in these?

[dhensby]

Yep, is a pretty serious bug, it's all about time for free at the moment... :(

[tractorcow]

This API has changed a lot in later branches... you probably don't want to leave this too long before the branches diverge. :P

I would close and re-open on 3.3 if I were you.

[kinglozzer]

Just ran into this one, nasty 😢 . Don’t suppose you’ve had a chance to look at this yet @dhensby?

[kinglozzer]

My example also needed !$this->query->isJoinedTo($componentClass) added to this condition

[dhensby]

Hmm.. maybe you'd need to do that if the field that needed to be filtered on was not on the componentBaseClass?

[dhensby]

I've gone and refreshed my memory with this issue. There are two problems here which I've now resolved, though perhaps not completely and in a very hacky and non-semver way.

1. Empty FROM clause when joining to the same table as the base table.

I think this has been resolved, though @kinglozzer doesn't seem to agree. Because DataQuery stores the joins and FROM clauses in the same keyed array, a join would just override the from and it'd be empty. This is fixed by checking that the table isn't already "joined" before adding the join.

1. Self referencing relations fail

If you have a relationship between the same ancestor classes (eg: SomePage many-many SomeOtherPage) it will select base columns from SiteTree, try to join SiteTree again (but doesn't because of fix above) and then does a WHERE on SiteTree.

The generated SQL for SomePage::get()->filter('RelatedPages', array(1,2,3)); is something like:

SELECT "SiteTree".*
FROM "SiteTree"
INNER JOIN "SomePage_RelatedPages" ON "SomePage_RelatedPages"."SomePageID" = "SiteTree"."ID"
WHERE "SiteTree"."ID" IN (1,2,3) AND "SiteTree"."ClassName" = 'SomePage';

This fails to return results as the join is not done properly and should be something closer to:

SELECT "SomePage".*
FROM "SiteTree" AS "SomePage"
INNER JOIN "SomePage_RelatedPages" ON "SomePage_RelatedPages"."SomePageID" = "SomePage"."ID"
INNER JOIN "SiteTree" AS "RelatedPage" ON "SomePage_RelatedPages"."RelatedPageID" = "RelatedPage"."ID"
WHERE "RelatedPage"."ID" IN (1,2,3) AND "SomePage"."ClassName" = 'SomePage'

This is a difficult problem to solve as the SearchFilter needs knowledge that the relation has a common inheritance and the where clause will have been aliased out.