jurchiks

Ne visi lieto Vim.

Acīmredzot ne tā sapratu. Anyway, tāds variants man galīgi nepatīk.

class.Foo
{
->public.function.bar()
->{
->->$m.=.array(
->->->'a'...->=>.1,
->->->'aa'..->=>.2,
->->->'aaaa'->=>.4
->->);
->}
}

papildus tab pēc key izlīdzināšanas vienkārši, lai bik brīvāk un vizuāli nesaspiesti.

Kaut ko tu tur esi sajaucis, drīzāk jau papriekš ar atstarpēm un tad, kad atstarpes izlīdzinās, tālāk ar tabiem.

Iekopē šo kaut kādā HTML failā,  un atver browserī:

<pre>
a		=> b,
blabla	=> c,
txt		=> whatever
</pre>

atver inspect element un pamaini CSS rūļa tab-size izmēru.

sleep uz 10ms

yep, you're crazy.

Žēl, ka man darbā 99% visu datubāžu (neskaitot manis no nulles rakstīto projektu) ir MyISAM (arī pasūtījumu/grāmatvedības sistēmas datubāze). Pārkonvertēju vienā projektā 4 tabulas uz InnoDB (produktu bilžu galerija un saistītās tabulas) un jau bija būtiskas problēmas.

Problēma ir tajā, ka tad, ja citiem ir uzlikts tab width 4 chars, bet tev - 2 chars, tad tev viņu formatētais kods var attēloties salauzts (piem. kaut kāds key-value map ar aligned values, 2-3 tabi starp key/value), un ja tu kaut ko tur labosi tāpēc, ka tev attēlojas citādāk... Tad labi nebūs.

Labi, uztaisīju "pa vecam". Nočakarējos gan kādu laiciņu, galīgi galva šodien nestrādā...

Ko tad, ja 1. pieprasījums nobremzē, vai, mazums, kaut kas notiek ne tā?

 

Macro-scale piemērs: 2 menedžeri vienlaicīgi atver kaut kādu datu rediģēšanas lapu. Abi kaut ko izmaina, bet pirmais saglabā uzreiz, otro iztraucē pa skaipu un tas saglabā pēc pāris minūtēm.

Ja pieliek row-lock, tad sanāk, ka tikai viens menedžeris drīkst kaut ko rediģēt un visiem pārējiem tiem datiem nav pieejas, kamēr šams nesaglabā datus? Vai kā tas notiek?

Labāk tad saglabāt "originalValue" un saglabājot salīdzināt ar tabulas datiem, un ja originalValue sakrīt ar tabulu, tad apdeitot uz newValue, otherwise izmest paziņojumu, ka kāds cits jau saglabājis, vajag iečekot viņu izmaiņas.

 

Row lock gadījumā 2. pieprasijuma $article->loadById(123); gaidīs, līdz 1. pieprasījums pabeigs visas darbības ar šo rindu.

t.i. garantēti visiem cilvēkiem jāgaida vienam uz otru, kamēr visiem iepriekšējiem ielādēsies lapa...

 

 

Anyway, tāpat skaidrs, ka tev labāk patīk rakstīt plikus SQL query konkrētās datubāzes dialektā un ja ievajadzēsies pāriet uz citu DB, tad visu pārrakstīt.

Tas par row lock un transakcijām vispār beztēmā aizgāja...

Un vēl viena lieta - ja tev kodā mētājas apkārt vairākas references uz to pašu rowu (šajā gadījumā, vairāki objekti, kuri reprezentē to pašu rowu), tad tev ir citas problēmas, par kurām vajadzētu padomāt.

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".

Nē, es domāju reālu piemēru, nevis "izdomā pats". Iedod sample datus un tiem veiktās izmaiņas.

izmaiņa ir tāda, kuras biznesa loģika nav ierakstāma kverijā

piemēram?

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?

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.

Būtu jau labi, bet ko tad, ja vajag sarakstu ar jūzeru datiem? Pieņemsim, pēdējie 100 reģistrējušies? Visiem objektus taisīt?

Redz, atkal tā pati attieksme.

// blocked, vismaz vienu labu lietu pateici pa visu threadu

Nu, man vienkārši bija slinkums meklēt :)

Dabīgi, ka to es negaidu, bet ja katrs otrais viņa posts sūta "3 mājas tālāk", tad ne jau man ir problēmas.

That's still awful. Kāpēc gan nechainot callus un vispār kāpēc neveidot kaut kādu query objektu, kurš jau satur konkrētas where/having/group/limit/join etc. metodes tā vietā, lai taisītu šos callus uz pamata db objektu? Tā ir God klase, not good IMHO.

Man, piemēram, ir uztaisīts sekojoši:

DbHandler klase satur metodes "select()", "insert()", "update()", "deleteFrom()", kuras, attiecīgi, padod "DbSelect", "DbInsert", "DbUpdate" un "DbDelete" objektus, kuri jau tālāk satur konkrēti metodes darbībām, saistītām tieši ar to query tipu, kā arī kapsulē esošo query. Objektu var "echo $obj;" un izdrukās tajā esošo query. DbHandler pats satur tikai pamata connection darbības (connect, startTransaction/commit/rollback/getLastInsertId/quote/execute(plain sql w/ no rset)).

Attiecīgi parasts SELECT izskatās šādi:

$rset = DbHandler::getInstance()
    ->select(array('colA', 'colB'), 'table')
    ->where('colC > ?')
    ->limit(10)
    ->fetchAll(array('colCValue'));

Nav perfekti, jo ir daudzas lietas, ko šāds piegājiens ierobežo, bet pagaidām vēl nav bijušas būtiskas problēmas, vienmēr varu izsaukt arī konkrētā query objekta getStatement() metodi, kura atgriež PDOStatement, un tālāk jau rakstīt pliku SQL query, bet līdz tikai varbūt 2x ir bijusi nepieciešamība ko tādu darīt.

 

 

Edit: vispār tajā ellislab lapā ir gandrīz pašā apakšā rakstīts, ka method chaining ir atbalstīts (tikai PHP 5+, bet nedomāju, ka tā būtu kāda problēma). Tipa "$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);"

Da tu nekad nepiekrīti, tur jau tā problēma. Palasi pats savus postus, visur tikai "ej kaut kur citur", "es taču teicu", "es daru šādi" utt.

Tā nav diskusija, ja viens dalībnieks nav vispār ieinteresēts uzklausīt citu viedokli un tikai nodirš citus par viņu teikto. Ja tu esi tā noskaņots, tad tev nav vietas šādos forumos. Bojā te lieki noskaņojumu un viss.

Reizēm gan tā nav laba ideja, piemēram, ja kaut kur iemaldījušies trailing whitespace un gribās no tiem atbrīvoties. Un tad var sanākt šmuce, ja viss pārējais whitespace ir konvertēts tabs<->spaces.

 

P.S. @F4llacy - tu tāpat nevienam nekad nepiekrīti, tā kā good riddance.

dafuq? Kas tas par dīvainu query building interfeisu?

Bet tagad pēdējā laikā tādi gudrīši kā jurelis ir paņēmuši šo kā standartu un sākuši pieprasīt ievērot obligātā kārtā. Hell no.

Kurā caurumā es tev kaut ko pieprasu? Tu te nesāc apsaukāties, krutais atradies. Pasaki savu vārdu, paņirgāsimies par tevi arī.

Kādu ietekmi tu domā? FIG biedru sarakstā ir lielu projektu/freimworku founderi un svarīgas personas.

http://jsfiddle.net/vr6bF/2/

working example.