New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Result: fixed UNION for complex queries (LIMIT, ORDER BY,...) #109

Merged
merged 1 commit into from Apr 13, 2018

Conversation

Projects
None yet
2 participants
@janpecha
Collaborator

janpecha commented May 8, 2017

Našel jsem 2 bugy při použití UNION strategie.

  1. pokud do dotazu filtrem přidám klauzuli LIMIT, rozbije se generování dotazu a použije se jen jeho první část, tj. místo dotazu

    (SELECT [book].* FROM [book] WHERE [book].[author_id] = 1 LIMIT 1)
    UNION
    (SELECT [book].* FROM [book] WHERE [book].[author_id] = 2 LIMIT 1)

    se vygeneruje jen

    SELECT [book].* FROM [book] WHERE [book].[author_id] = 1 LIMIT 1

    takže nedojde k načtení všech dat. Problém způsobil pravděpodobně tento commit v dibi. Pokud se výsledek nelimituje, je vygenerovaný dotaz v pořádku.

  1. druhý bug souvisí s SQLite - jednotlivé UNION části nesmí být v SQLite zabaleny do závorek - to však znemožňuje použití komplexnějších dotazů - pokud do dotazu doplníme LIMIT nebo ORDER BY vyhodí nám SQLite chybu. Řešit se to dá pomocí subselectů:
SELECT * FROM (SELECT [book].* FROM [book] WHERE [book].[author_id] = 1 ORDER BY [pubdate])
UNION
SELECT * FROM (SELECT [book].* FROM [book] WHERE [book].[author_id] = 2 ORDER BY [pubdate])
@castamir

This comment has been minimized.

Show comment
Hide comment
@castamir

castamir May 13, 2017

Collaborator

Pouziti m:filter obecne nedoporucuju - jednak kvuli samotne registraci filtru, tak kvuli pouziti v entite, zejmena pri vyskytu u vice property zaroven - vznikaji tim jen problemy (napr u 2 property je orderby, jak se to ma seradit?). Doporucuju pouzivat pristup tvorby dotazu pres QueryObject.

Collaborator

castamir commented May 13, 2017

Pouziti m:filter obecne nedoporucuju - jednak kvuli samotne registraci filtru, tak kvuli pouziti v entite, zejmena pri vyskytu u vice property zaroven - vznikaji tim jen problemy (napr u 2 property je orderby, jak se to ma seradit?). Doporucuju pouzivat pristup tvorby dotazu pres QueryObject.

@janpecha

This comment has been minimized.

Show comment
Hide comment
@janpecha

janpecha May 13, 2017

Collaborator

Jj, m:filter taky obecně nedoporučuju, ale v některých případech se hodí anonymní filtr (objekt Filtering) a tam vznikne stejný problém - syntax error, případně špatně sestavené SQL.

BTW jak myslíš to "napr u 2 property je orderby, jak se to ma seradit?" ?

Collaborator

janpecha commented May 13, 2017

Jj, m:filter taky obecně nedoporučuju, ale v některých případech se hodí anonymní filtr (objekt Filtering) a tam vznikne stejný problém - syntax error, případně špatně sestavené SQL.

BTW jak myslíš to "napr u 2 property je orderby, jak se to ma seradit?" ?

@castamir

This comment has been minimized.

Show comment
Hide comment
@castamir

castamir May 13, 2017

Collaborator

no mas 2 property (X a Y) s anotaci m:filter(#orderby)
vysledny dotaz ma byt order by X nebo order by Y nebo oboje zaraz a pokud oboje, v jakem poradi?


jeste dodam, ze problem muze byt skryty v pripade dedicnosti a zejmena pak tezko upravitelny, pokud uz tam jeden takovy filtr je - dojde k ovlivneni vsech dotazu na danou entitu. To samo o sobe je duvodem, proc m:filter vubec nepouzivat

Collaborator

castamir commented May 13, 2017

no mas 2 property (X a Y) s anotaci m:filter(#orderby)
vysledny dotaz ma byt order by X nebo order by Y nebo oboje zaraz a pokud oboje, v jakem poradi?


jeste dodam, ze problem muze byt skryty v pripade dedicnosti a zejmena pak tezko upravitelny, pokud uz tam jeden takovy filtr je - dojde k ovlivneni vsech dotazu na danou entitu. To samo o sobe je duvodem, proc m:filter vubec nepouzivat

@janpecha

This comment has been minimized.

Show comment
Hide comment
@janpecha

janpecha May 13, 2017

Collaborator

Tak to by neměl být problém - buď přistupuješ přes $entity->x (a dotáhnou se data s ORDER BY x), nebo přes $entity->y (a dotáhnou se data s ORDER BY y). Ale rozhodně souhlasím, že filtry se většinou nevyplácí příliš kombinovat a je lepší použít query object.

Collaborator

janpecha commented May 13, 2017

Tak to by neměl být problém - buď přistupuješ přes $entity->x (a dotáhnou se data s ORDER BY x), nebo přes $entity->y (a dotáhnou se data s ORDER BY y). Ale rozhodně souhlasím, že filtry se většinou nevyplácí příliš kombinovat a je lepší použít query object.

@janpecha

This comment has been minimized.

Show comment
Hide comment
@janpecha

janpecha Aug 30, 2017

Collaborator

Dnes jsem na tento problém znovu narazil v souvislosti s LeanMapperQuery - mibk/LeanMapperQuery#3

Collaborator

janpecha commented Aug 30, 2017

Dnes jsem na tento problém znovu narazil v souvislosti s LeanMapperQuery - mibk/LeanMapperQuery#3

@janpecha janpecha added this to the Stable 3.2.0 milestone Apr 12, 2018

@janpecha janpecha merged commit 67862cd into Tharos:develop Apr 13, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@janpecha janpecha deleted the inlm:pr/bugfix-union-limit-orderby branch Apr 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment