Laravel composite PK

[EdgarsN]

Sveicināti!

 

Mana problēma bija izdzēst ierakstu no Eloquent (lasīt: tabulas), kurā nav ID kolonnas, bet tā vietā 3 PK kolonnas.
Papildus nosacījums: jāizpildās Laravel Eloquent deleting/deleted eventiem.

 

Šādi rakstot nenostrādā event'i:

Model::where('x', $x)->where('y', $y)->where('z', $z)->delete();

Mans risinājums šai problēmai:

Model.php fails.

protected $primaryKey = ['x', 'y', 'z'];
protected $incrementing = false;

/**
 * Set the keys for a save update query.
 *
 * @param  \Illuminate\Database\Eloquent\Builder  $query
 * @return \Illuminate\Database\Eloquent\Builder
 */
protected function setKeysForSaveQuery(Builder $query)
{
	if (is_array($this->primaryKey)) {
		foreach ($this->primaryKey as $key) {
			$query->where($key, '=', $this->original[$key]);
		}

		return $query;
	}

	return parent::setKeysForSaveQuery($query);
}

Dzēšanas izsaukšana:

$item = Model::where('x', $x)->where('y', $y)->where('z', $z)->first();
$item->delete();

Kādi ir jūsu risinājumi? Varbūt jums ir kāds daudz labāks risinājums, ko neesmu atradis? :)

 

Paldies.

[briedis]

DB::where('x', $x)->where('y', $y)->where('z', $z)->first();

 

Nu nestrādā īsti tie eloquent modeļi ar vairākiem PK laukiem. Visi šādi workaround ir haki.

 

Uztaisi labāk klasi/servisu/libu/repositoriju, kas menedžē šādas lietas. Uztaisi pliku klasi, kas satur šos laukus. Repositorijs vnk atgriež masīvu/instanci ar šo klasi. Nevajag šādi hakot, būs grūti uzturēt, veikt izmaiņas...

[EdgarsN]

Ok, paldies Tev par atbildi. Ņemšu vērā un izvairīšos no šādas lietas.

[briedis]

Var arī vienkārši klasi, kurai ir save/delete/find metode.

$yourClass = YourClass::find($id1, $id2, $id3); // Taisa DB::select(), saliek vērtības objekta public propertijos un atgriež klases objektu
$yourClass->something = 1234;
$yourClass->save(); // uztaisa insert vai update balstoties uz iekšējiem propertijiem ar DB::update/insert
$yourClass->delete(); // izsauc DB::delete() ar dotajiem parametriem.

Jāņem gan vērā, ka te būs nedaudz čakars ar relācijām. Ja vajag relācijas, tad tomēr labāk ir unikāls ID (uztaisi unique key'u uz vajadzīgajiem 3 laukiem).

Ja objektus izgūsti no DB ar kaut kādu vienotu klasi, tad principā vari simulēt to, ka it kā tie 3 lauki ir primary, bet patiesībā ir viens unikāls ID tāpat. Sanāk tāds DataMapper patterns ~ http://designpatternsphp.readthedocs.io/en/latest/Structural/DataMapper/README.html

 

 

 

Varianti ir visādi, bet, manuprāt, eloquent internālo metožu overraidošana tomēr ir riskanta. Kāds vēl izdomās joinot, relācijas taisīt utt un tad būs mērendz murdziņš saprast, kas patiesībā notiek.

[EdgarsN]

Šajā gadījumā relācijas nebija nepieciešamas, taču paldies, ka norādīji uz iespējamu problēmu :)

Pārdomāju visu tavu rakstīto un tomēr pieturēšos pie ID. Galu galā pats vairs beigās nesapratu kāpēc vēlējos atteikties no ID, jo īsti man tāpat tas netraucē.

[briedis]

Pārdomāju visu tavu rakstīto un tomēr pieturēšos pie ID.

 

Esmu ar šo dillemu saskāries N-tās reizes. Principā vienmēr paliku pie ID, bet ar vairāku kolonnu unique lauka. Ar eloquent vnk atkrīt liels čakars strādājot ar objektiem.

[Mr.Key]

Eloquentam nav nekādu īpašu priekšrocību, turklāt composite PK atbalsta trūkums ir smieklīgs! To atbalsta pat arhaiski brīnumi. Eloquent ir reliģisks, nevis praktisks risinājums. Vajadzības pēc viņa nav, ja neskaita to, ka daži autori apmierina savas ambīcijas.

[briedis]

Eloquentam nav nekādu īpašu priekšrocību, turklāt composite PK atbalsta trūkums ir smieklīgs! To atbalsta pat arhaiski brīnumi. Eloquent ir reliģisks, nevis praktisks risinājums. Vajadzības pēc viņa nav, ja neskaita to, ka daži autori apmierina savas ambīcijas.

 

</rant> :)