jurchiks Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) 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 August 13, 2013 by jurchiks Quote Link to comment Share on other sites More sharing options...
daGrevis Posted August 13, 2013 Report Share Posted August 13, 2013 > Visiem objektus taisīt? Protams. Pag, kā vispār savādāk?? > Scalā es daru šadi: Pythonā es daru šādi: https://github.com/daGrevis/daGrevis.lv/blob/master/dagrevis_lv/blog/views.py#L19 Quote Link to comment Share on other sites More sharing options...
codez Posted August 13, 2013 Report Share Posted August 13, 2013 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). Quote Link to comment Share on other sites More sharing options...
F3llony Posted August 13, 2013 Report Share Posted August 13, 2013 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. Quote Link to comment Share on other sites More sharing options...
codez Posted August 13, 2013 Report Share Posted August 13, 2013 Pythonā es daru šādi: https://github.com/daGrevis/daGrevis.lv/blob/master/dagrevis_lv/blog/views.py#L19 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? Quote Link to comment Share on other sites More sharing options...
Леший Posted August 13, 2013 Report Share Posted August 13, 2013 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. Quote Link to comment Share on other sites More sharing options...
jurchiks Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) 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 August 13, 2013 by jurchiks Quote Link to comment Share on other sites More sharing options...
codez Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) 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 August 13, 2013 by codez Quote Link to comment Share on other sites More sharing options...
jurchiks Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) izmaiņa ir tāda, kuras biznesa loģika nav ierakstāma kverijā piemēram? Edited August 13, 2013 by jurchiks Quote Link to comment Share on other sites More sharing options...
codez Posted August 13, 2013 Report Share Posted August 13, 2013 piemēram? Katram saglabājamajam ierakstam ir sava unikāla vērtība, kas nav atkarīga no iepriekš ierakstā esošajām vērtībām. Quote Link to comment Share on other sites More sharing options...
jurchiks Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) Nē, es domāju reālu piemēru, nevis "izdomā pats". Iedod sample datus un tiem veiktās izmaiņas. Edited August 13, 2013 by jurchiks Quote Link to comment Share on other sites More sharing options...
daGrevis Posted August 13, 2013 Report Share Posted August 13, 2013 > 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 Quote Link to comment Share on other sites More sharing options...
codez Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) > 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 August 13, 2013 by codez Quote Link to comment Share on other sites More sharing options...
jurchiks Posted August 13, 2013 Report Share Posted August 13, 2013 (edited) Tu tikai pieliki "FOR UPDATE"... domā, abstrakcijai tas būtu baigi grūti panākams? Kā arī, neredzu, kur tu explicitly pateiktu "sākam transakciju un ieslēdzam row lock". Edited August 13, 2013 by jurchiks Quote Link to comment Share on other sites More sharing options...
daGrevis Posted August 13, 2013 Report Share Posted August 13, 2013 Nebūtu un tas ir zināms fakts, ka ORM (vai sauc kā gribi) ir savi ierobežojumi. Arī, ir plusi. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.