Jump to content
php.lv forumi

mysql dalisana - CI


goma smile

Recommended Posts

Tā abstrakcija ir domāta, lai būtu iespēja pārslēgties uz citu datubāzi bez būtiskām problēmām (mazums, piemēram, sagribās no MySQL uz PGSQL pāriet). Ja tev visur ir ar roku rakstīti SQL query, tad tā būs, kā būs.

Edited by jurchiks
Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Tā abstrakcija ir domāta, lai būtu iespēja pārslēgties uz citu datubāzi bez būtiskām problēmām (mazums, piemēram, sagribās no MySQL uz PGSQL pāriet). Ja tev visur ir ar roku rakstīti SQL query, tad tā būs, kā būs.

 

Tas nav attaisnojums, lai rakstītu murgainu abstrakcijas slāni un tam sekojošo kodu, lai kaut kad, ar nelielu varbūtību, būtu iespējams nomainīt db.

Tad jau daudz labāk izmantot to pašu Active Record (bet īsto, nevis to, par kuru tādu sauc CI).

Link to comment
Share on other sites

Neviens neraksta PHP aplikācijas pret vienu DB kad tu zini, ka vēlāk tev viņa būs jāpārnes uz citu DB. Nu nevar speciāla mērķa aplikāciju efektīvi uzrakstīt tik tiešām dzinēja neatkarīgu, nevar. Pārnešana no dzinēja uz dzinēju vienmēr prasīs modificēt kodu. Abstrakcija PHP un DB kontekstā šeit ir vairāk abstrakcionēt DB darbības kā PHP devam draudzīgas un pazīstamas darbības, nejau DB dzinējus. Tas arguments ir invalīdāks kā vidējais statistiskais nodokļu inspektors. 

Link to comment
Share on other sites

 

Kā tu pythonā(django) izdarītu tā, ka tu ielādē teiksim 10 rakstus, dažiem ierakstiem izmaini vienu lauku un tos updeito, bet tā, lai tas viss notiktu vienā transakcijā un uz attiecīgajām ielādētajām rindām būtu uzlikts row lock?

Link to comment
Share on other sites

Nez kāpēc visi ir pārliecināti, ka abstrakcijas domātas, lai varētu bieži pārnest uz citu DB. Cik bieži jūsuprāt pasaulē kāds pārnes projektu no mysql uz prostgre piemēram?

Abstrakcijas ir domātas, lai nebūtu jāpārrakstā kodu, ja notiek kaut kādas izmaiņas db, kaut vai refaktorings.

Link to comment
Share on other sites

Tas nav attaisnojums, lai rakstītu murgainu abstrakcijas slāni un tam sekojošo kodu, lai kaut kad, ar nelielu varbūtību, būtu iespējams nomainīt db.

Tad jau daudz labāk izmantot to pašu Active Record (bet īsto, nevis to, par kuru tādu sauc CI).

Lets agree to disagree then. Man gluži vienkārši nekad nav bijusi vajadzība turēt visus, piemēram, klientus katru savā objektā, man pietiek ar masīvu, un ja es kaut ko izmainu, tad UserManager::update($id, array('name' => 'the new name')).

 

@Леший - tu laikam domā tādas abstrakcijas, kurās tādam User objektam ir savi getteri/setteri, bet db kolonnas nosaukums ir privāts un to var mainīt, kā grib? Vai par kādu refaktoringu tu runā, kas tā varētu lauzt querijus, bet neietekmēt abstrakcionētas sistēmas?

Edited by jurchiks
Link to comment
Share on other sites

Lets agree to disagree then. Man gluži vienkārši nekad nav bijusi vajadzība turēt visus, piemēram, klientus katru savā objektā, man pietiek ar masīvu, un ja es kaut ko izmainu, tad UserManager::update($id, array('name' => 'the new name')).

 

Okey, tev tas pats piemērs, kas daGrevis.

Ielādejam rakstu sarakstu no db un pēc kaut kāda parametra izmainām daļai rakstu kādu kolonnu (izmaiņa ir tāda, kuras biznesa loģika nav ierakstāma kverijā) un tālāk saglabājam izmainītās kolonnas tā, lai tas vis snotiktu vienā transakcijā un butu rowlocks uz ielādētajām rindām. Kā tu darītu PHP?

Edited by codez
Link to comment
Share on other sites

> Kā tu pythonā(django) izdarītu tā, ka tu ielādē teiksim 10 rakstus, dažiem ierakstiem izmaini vienu lauku un tos updeito, bet tā, lai tas viss notiktu vienā transakcijā un uz attiecīgajām ielādētajām rindām būtu uzlikts row lock?

 

Nezinu par raw lock, bet...

 

http://vpaste.net/dZe8f

Link to comment
Share on other sites

> Kā tu pythonā(django) izdarītu tā, ka tu ielādē teiksim 10 rakstus, dažiem ierakstiem izmaini vienu lauku un tos updeito, bet tā, lai tas viss notiktu vienā transakcijā un uz attiecīgajām ielādētajām rindām būtu uzlikts row lock?

 

Nezinu par raw lock, bet...

 

http://vpaste.net/dZe8f

 

Tavā piemērā tu izmanto abstrakcijas slāni, kurš ielāde objektu kolekciju, bet problēma ir tā, ka tas abstrakcijas slāni imitē SQL. Būtībā viņš nepadara neko īpaši abstraktāku, tikai to pašu SQL, tu raksti pythonā. Bet ar visām šim abstrakcijām problēma ir tā, ka viņan parasti pilnībā neimplementē visu funkcionalitāti. Un šijā gadījumā runa ir tieši par row lock, kurš ir svarīgs.

Row lock noloko rowu līdz transakcijas beigām, lai kādā citā pieprasijumā nevarētu ielasīt datu. Ja nav row locka, tad kāds cits pieprasījums pēc datu ielādes, bet pirms saglabāšanas var ielasīt tos pašus datus un saglabāt pēcāk pa virsu jau saglabātajiem no pirmā pieprasījuma.

Scalā es to darītu šādi:

SQL("SELECT * FROM `things` WHERE `is_foo` IS TRUE LIMIT 10 FOR UPDATE").select().as[Thing].filter(_.isBar()).map(_.update())

Kā redzams rakstot plain kveriju es varu izmantot tās fičas, kuras abstrakcijā var būt nepieejeamas.

Edited by codez
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...