OrderBy over hasMany returns wrong data

[qwerin]

To Reproduce

$authorsOrderby=$this->orm->authors->findAll()->orderBy('books->title');
$authors=$this->orm->authors->findAll();
Assert::same($authorsOrderby->count(),$authors->count());

To Fix
Remove this Line:

orm/src/Collection/DbalCollection.php

Line 332 in af22260

$groupBy = array_merge($groupBy, $expression->columns);

Versions::

• Database: MariaDB 10.8.8
• Orm: 5.0.1
• Dbal: 5.0.1

[hrach]

Thank you for the report.

This seems to be an "unsupported" use case. How would you like the collection to be sorted when an author has more than one book? This doesn't make much sense. The implicit ANY aggregator doesn't make sense.

Did it work in Orm 4? If so, I guess it was just a coincidence and the sorting didn't produce anything "valuable", did it?

[qwerin]

Usecase select product and order by variant.price. Yes in Orm 4 its ok.

[hrach]

The product has many variants, but you want to sort it by a single variant, so technically, in the example, there is a missing findBy(), isn't it?

If you add sufficient filtering to make hasMany "become hasOne", then it behaves correctly and there is no issue.

I am not against fixing this, but I fail to see how this should behave at first. IMO, this is rather undefined, and it shouldn't throw an exception.

This example with added filtering passes the test:

$authorsOrdered = $this->orm->authors
	->findBy(['books->genre' => GenreEnum::SCIFI])
	->orderBy('books->title');
$authors = $this->orm->authors
	->findBy(['books->genre' => GenreEnum::SCIFI]);
Assert::same($authorsOrdered->count(), $authors->count());

note: the filtering ensures there is just a single scifi book for authors. that's because the testing data set looks lite that.

[qwerin]

Ano produkty maji vice variant a ano fineBy jsem tam nedal neni podstatne.. chyba se projevi tak ci tak.

Ok, jinak mas tam malo dat staci to upravit aby to se vybrali alespon 2 autori napr.

$authorsOrdered = $this->orm->authors
	->findBy(['books->genre!=' => GenreEnum::SCIFI])
	->orderBy('books->title');
$authors = $this->orm->authors
	->findBy(['books->genre!=' => GenreEnum::SCIFI]);
Assert::same($authorsOrdered->count(), $authors->count());

Spis nechapu proc se do groupBy pridava automaticky sloupce orderBy

ps. nevim proc mi u tohoto prikladu test na php 8.3 vraci

E_WARNING: Array to string conversion in Collection/Helpers/ArrayCollectionHelper.php(87)

Jinak diky za super praci na nextras :-)

[hrach]

Dobre, tak zkusim popsat znovu, co nechapu a proc si myslis, ze ti to fungovalo dobre. Ukazu to nazorne na prikladu v PHP:

$products = [
[
     'title' => 'PHP Book',
     'variants' => [['variantTitle' => '8.1'], ['variantTitle' => '7.4']],
],
[
     'title' => 'MySQL Book',
     'variants' => [['variantTitle' => '8.1'], ['variantTitle' => '7.4']],
],
];

A ty mi rikas, ze chces knihy seradit podle titlku jejich variant. A ja se ptam, jaky? Prvni? Posledni? Prumerny? Proto se tam musi dofiltrovat na jednu variantu. Pak to funguje spravne. Dokud to nedofiltrujes na jednu variantu, tak nevim jaky by to chovani melo byt.

To, ze to v Orm 4 nejak fungovalo je sice side effect, ze ta implementace delala nejakou "nahodnou" implemtanci - vychazejici z SQL. A nejakou nahodnou v PHP.

[qwerin]

Taky popisu mozna je to jen ma neznalost vnitrniho fungovani sql obecne ale DB:

products = [
[
     'title' => 'PHP Book',
     'onEshop' => true,
     'variants' => [['variantTitle' => 'paper', price=150], ['variantTitle' => 'e-book', price=100]],
],
[
     'title' => 'MySQL Book',
     'onEshop' => true,
     'variants' => [['variantTitle' => 'paper', price=250], ['variantTitle' => 'e-book', price=150]],
],
[
     'title' => 'Java Book',
     'onEshop' => true,
     'variants' => [['variantTitle' => 'paper', price=350], ['variantTitle' => 'e-book', price=150]],
],
];

pokud chci seradit produkty podle ceny pak:

$products = $orm->products->findBy(['onEshop'=>true])->orderBy('variant->price');

SELECT product.* FROM `product` LEFT JOIN variant ON product.id=variant.product_id WHERE product.onEshop=1 GROUP BY product.id ORDER BY variant.price

Ocekaval bych ze mi to vrati 3 knihy v poradi PHP book pak je to otazka nahody (asi by id) MySQL a Java book.

Momentalne to je implementovane tak ze to vrati 6 knih jakoby pokazde s jinou variantou

pak kdyz je bude iterovat na vylistovani produktu tak:

foreach ($products as $product){
    echo $product->title;
    foreach ($product->variants as $variant){
        echo $variantTitle->name." ".$variantTitle->price;     
    }
}

Tak se produkty vypisi Xkrat. A jeste vetsi paseku udela limit offset strankovani.

Asi to pouzivam spatne :-) Pises ze se to musi dofiltrovat na jednu variantu souhlasim neco jako min(variant.price) .. to nevim jak.
Takze jak to spravne zadat v ORM abych vypsal na stranku 20 produktu razenych podle ceny ktera je ulozena ve variantach ?

[qwerin]

jinak tady je example projekt
https://github.com/qwerin/nextrasOrmTest

co je zajimave tak varianty se dotazuji nekolikrat

SELECT `variant`.* FROM `variant` AS `variant` WHERE `variant`.`product_id` IN (1, 1, 3, 2, 2, 3)

[demmmmios]

Narazil jsem na stejny use case dnes. Mam produkty v tabulce a a preklady produktu v tabulce b. Pokus radim podle prekladu (tedy transtalions->name) tak jsou ve vysledne kolekci produkty duplictne podle poctu jazyku (tedy napr 5x stejny produkt). Ano spravne bych mel radit pouze podle jednoho jazyku, ale spis je spatne ze ta kolekce nevraci unikatni zaznamy kdyz se pak zacne foreachovat. Je zadouci aby kolekce vracela obejkty pod stejnym id vicekrat?

[hrach]

@demmmmios chces rict, ze u as to neni problem jenom pro count, ale i pro listing? mohl by jsi prosim poslat kod?

[demmmmios]

je to zmíněné zde #728 (comment) že se produkty vypíšou x krát (dle počtu navázaných variant protože tam je leftjoin a pak už se neřeší deduplikace v kolekci), to je stejný problém takže ten example už tu je

[hrach]

Tento ticket me popravde netesi. Pouzivate Orm/DB spatne, respektive, nahodou vam to na prvni pohled vraci (vracelo) data, ktera vam vyhovuji.

Kdyz napr. vezmu odpoved v #728 (comment)

Ocekaval bych ze mi to vrati 3 knihy v poradi PHP book pak je to otazka nahody (asi by id) MySQL a Java book.

Jako proc by mela byt PHP book vracena prvni? Protoze ma variantu s nejmensi cenou?
Tak to prosim se tam musi dat agregace. Protoze nikdo nikomu nezakazuje, aby se pri vypoctu vzala jakakoliv varianta a podle ni seradilo. Da se pak ocekavat, ze vsechny tri produky maji variantu s cenou 150, tj. vsechny vlastne muzou byt vraceny v uplne nahodnem poradi.

V Orm 5 (a slo to uz i v Orm 4, jestli si dobre pamatuju), je proste spravne tam pouzit agregaci takto:

$products = $orm->products->findBy(['onEshop'=>true])
    ->orderBy([MinAggregateFunction::class, 'variant->price']);

A najednou se to bude chovat spravne, bude to vracet spravna data, i v PHP.

A to je muj druhy zasadni problem: Orm stavi na tom, ze je jedno, jestli data jsou v db nebo v runtime, nebo kdekoliv jinde. Proto ja musim a chci to chovani reimplementovat do ArrayCollection. A jestli vase odpoved, to je jedno, je to nedefinovany, predtim to nejak fungovalo, tak to je proste pro me strasne malo, s tim nemuzu pracovat.

---

Asi se jeste podivam do kodu, jestli je nejaka cesta, aby se ten group by nepridal, ale spis neni a vysvetlim na nasledujicim prikladu:

• pracujme stale s danou strukturou, "product hasMany variants"
• nyni ale u variants pridejme priznak, ze dana varianta je aktivni a mejme "pravidlo", ze bude vzdy aktivni jen jedna varianta (v podstate obdoba prekladu, kdy chci radit produkty jen podle aktivniho jazyka, tj. jednoho prekladu).

Vyleze z toho cca tento zapis:

$orm->products->findBy(['variant->active' => true])->orderBy('variant->price');

Najednou nemame ani semantickou, ani praktickou potrebu pouzivat agregacni funkcni. A zaroven, cena varianty se musi objevit v group by, protoze by (min. Postgres) jinak nebyl ochoten podle ni vysledky seradit. Pokud je dodrzeno, ze je jen jedna aktivni varianta, zadne duplikaty vraceny nejsou a vse funguje.

Problem je, ze to, ze se nevrati vic radku, Orm nemuze pred vykonani dotazu vedet a tim padem nemuze podle toho dany dotaz jinak generovat.