Nextras ORM – přístup k datům v spojovací tabulce

Další entita to bude pak generovat více dotazů do db. Musel bych získat tedy item z nej storage a pak podle id itemu a id storage vytahnout množství. Nějaká možnost jak udělat elegantněji návrh db? Tohle je myslím dost častý případ kdy jsou dvě entity spojené s nejakým parametrem.

Líbilo by se mi třeba kdyby orm udělalo na entitě „proxy“ variable. $item->storage->quantity ? $storage->item->quantity?

Ďalší návrh: v entite k danej property pridať modifikátor.

/**
 * @property int $quantity {relational column=quantity}
 */
class Storage extends Entity {}

A klasicky zvládať aj insert.

$storage = new Storage();
// ...
$storage->quantity = 2;

$item->add($storage);

To je takový „chci používat orm, ale teď zrovna ho použít nechci“

Pokud jde jen o to ta data vytáhnout efektivně, tak by dávalo smysl řešit, jak vylepšit dotazování. Místo řešení, jak nenapsat jednoduchou entitu.

Ono to ma zaujimavo eloquent, ako tu uz zaznelo:

return $this->belongsToMany(Role::class)->withPivot('active', 'created_by');

Ale to platí len pre dotazovanie asi (moc do hlbky som to neskumal), neviem ako sa to tam robi pri inserte.

Bolo by fajn, kebyze to ORM umoznuje, ale da sa zit aj bez toho, kedze riesenie existuje. Len clovek namiesto 2 entit definuje 3.

Díky za odkaz na Eloquent – to automaticke injectovani spravneho pivotu je zajimave:

use App\Models\User;

$user = User::find(1);

foreach ($user->roles as $role) {
    echo $role->pivot->created_at;
}

Trochu se to podoba tem Metadata, co jsem sdilel nahore, tzn. nutnost define te spojovaci tridy. Akorat timto API by to bylo asi akceptovatelnejsi. Bohuzel si myslim, ze to nebude bezpecne fungovat.

Neco podobneho uz mame v Orm, ze podle toho, odkud entitu accessujes, se pouzije preoptimalizace pro dotazeni dat odjinud. Tzn. jedna se o performance optimalizaci. Meneni ale pivotu podle toho, odkud clovek na entitu prisel, mi prijde extremne nebezpecne. A vlastne v Eloquentu je to mozne jen proto, ze nemaji IdentityMapu, jestli jsem to spravne pochopil.

hrach napsal(a):

Řešení to samozřejmě má. Jde jen o to že by to bylo pěkné mít to v rámci orm.

$item = $this->orm->item->getById(12)
foreach($item->storage as $storage){
	$quantity = $storage->quantity;
}

To je ten problem. Storage je stejna instance az uz je vytazena pres item#12 nebo item#13, protoze IdentityMapa.
Takto to fungovat nemuze.

To je stejná instanace storage i když item12 a item13 každý má napárovaný jiný storage ?

U nás úplně základní příklad, kdy máme entitu Product a Category a zadání je mít možnost řadit v každé kategorii produkty jinak. K tomu se perfektně hodí tabulka m:m se sloupcem position navíc. Aktuálně to řešíme přes 3 entity, ale je to trochu takový kostrbatý ta práce s tím. Zde je jasné, že tohle prostě integrovat do ORM není úplně easy a asi se zde budeme muset smířit s více entitami.

Když už se tu řeší tohle tak bych měl taky jednu takovou prkotinu, která je navíc v eloquentu a to je firstOrCreate. Tedy v nextras by to bylo něco jako getByOrCreate. V praxi to zkracuje takový ten rutinní zápis, kdy kontrolujeme vrácenou entitu vůči null a pak ji vytváříme když není a attachujeme… Ano je možné si to napsat do nějakého abstract repository, ale radši bych byl za interní integraci. trochu info k tomu zde: https://laravel-news.com/…dateorcreate

Jedeme většinu aplikací v nextras/orm ale občas je dobré se inspirovat jak to mají dělané jinde a ulehčit si to