IBX-12335: Fixed field criterion querying on invalid table when translation table is joined

[barw4]

🎫 Issue	IBX-12335

Description:

ExpressionVisitor::walkComparison() routed a column into the translation subquery whenever the _ml table had a column with that name, without checking the main table first. Every _ml table has its own id primary key, so filtering by entity id silently compared translation-row ids instead:

-- FieldValueCriterion('id', 2), expected:
main.id = 2

-- actual:
main.id IN (SELECT t.main_id FROM main_ml t WHERE t.main_id = main.id AND t.id = 2)

With one translation per entity both ids happen to be equal, so results looked correct. They diverge as soon as any entity has a second translation - the query then returns the wrong entity (confirmed via public API in ibexa/payment).

Now a column defined on the main table always targets the main table; only columns existing solely on the translation table are resolved through the translation subquery.

For QA:

Documentation:

[Steveb-p]

Wouldn't it be more correct to "merge" this special case (translation column) with the later logic block (i.e. return instead of throwing an exception if there's a translated column)?

[barw4]

Done dda36d7

[bnowak]

Why we're combining (SQLite) integration tests together with unit tests into single CI job?

If we have already splitted jobs for postgres/mysql, can we do the same with SQLite? IMO it's more consinstent approach

[barw4]

@bnowak https://github.com/ibexa/core/blob/4.6/.github/workflows/backend-ci.yaml#L31 we do the same in core

[bnowak]

Is core a good example tbh? Do we have more packages following that pattern?

[Steveb-p]

Core is a bit of an exception, but the pattern is good and expected - SQLite integration tests usually depend on unit tests passing to conserve github minutes, and execute after - the preceeding setup is almost - if not always - exactly the same, so we don't need to waste extra processing just to checkout and run initial build.