F3llony

+1 mad182

Šis jau sen (vispār nekad nav bijis) nav īsti arguments. Ja konfigu adminam jāmaina biežāk kā 1 reiz (:D). tad adminam ir nevis jālien konfigos bet jāizmanto tam paradzēti tūļi (puppet, for example). Ja tas nav bieži, tad tam nav nozīmes īsti, jo, well, tas nav bieži. Un es nedomāju, ka mēs īsti spētu arī gribot izgudrot tādu formātu kas reizē būtu izmantojams un būtu vēl sliktāks par jau /etc/ atrodamajiem murgojumiem :D Un tas, ka lasa/lieto 99% gadījumu PHP pilsonis, tas jau tā kā būtu saprotams pēc topika. Tavi saskaldītie mati ir īsti dredi. Es pat nesaprotu, kā par šo piemirsu.

Pilnīgi piekrītu, un daudzos gadījumos to tiešām tā var arī realizēt, bet diemžēl, ne tuvu ne visos.

Faceplam some more. Puppet does not care about your formatz.

:D es saprotu, ka tu esi trāpijis uz kaut kādu energo vai telekoma iepirkumu, bet šitā ķēmošanās NAV normāls gadījums. Tas nekas, ka tā dara. Un kodu pa epastu sūtīt arī nav normāls gadījums.

Sekcija=>konfigs=>vērtība[?masīvs/saraksts] Offtopic protams, bet kādā normālā gadījumā gar PHP aplikāciju konfigiem gramstās admini?! Lūdzu, pastāsti man, kurā paradīzes ielejā tā notiek. Konfigs ir tāds pats klasisks write few, use many gadījums kā ārējās bibliotēkas. Konfigs tiek referencēts bieži tāpēc tam būtu jābūt maksimāli ērtam, tieši tā pat, kā jebkurai tāda paša tipa referencei. Asociatīvi masīvi šajā gadījumā ir problemātiski jo tiem nav definējama shēma un nav tik ļoti vēlamais autocomplete.

Datubāzē nekad neglabā laiku N laika zonās, izvēlas pamata (piem. GMT+0) un tajā arī glabā. Laika zonas rēķina pie prezentācijas un datu saņemšanas relatīvi pamata laika zonai, ja vispār ir tāda nepieciešamība. Normālā gadījumā pie datu saņemšanas izmanto aplikācijas vienoto laiku, e.g. to laika zonu, kurā darbojas visas sistēmas un ja nepieciešams, laika izvadi koriģē tikai pie prezentācijas. Jebkurā gadījumā, unixtime nekādā veidā neatrisina, vienkārši unixtime vienmēr izmanto UTC. Noskaties šo - https://www.youtube.com/watch?v=-5wpm-gesOY also http://dev.mysql.com/doc/refman/5.6/en/datetime.html

Domā, ka ja viņam tur ir bardaks arī ieteikumam ir jābūt tik pat lielam bardakam? Tādā veidā jams toč neko neiemācīsies.

Tāpēc, ka wow MySQL such database much use wow tables.

Kā jau minēju, nevajag datubāzē glabāt datumu kā unix time skaitli. Pārtaisi tabulu lai izmanto DATETIME kolonnas tipu un ierakstu veic izmantojot nevis time() bet MySQL NOW(), piemēram, INSERT INTO tabula SET [...], `date` = NOW();

NEKAD šādi nedari. Šeit date tiks aprēķināts visām kolonnām, arī tām, kas neatbilst un nevarēsi izmantot indeksu. [...] WHERE `date` BETWEEN '2014-12-29 00:00:00' AND '2014-12-29 23:59:59' Vēl daži do's and dont's: MySQL datumus un datumu laiku glabā nevis kā skaitli, bet kā DATE vai DATETIME. No POST/GET formas saņemto vērtību pārsē nevis ar strtotime, bet ar DateTime PHP klasi. strtotime pārvērš ievadīto datumu unix timestamp, kas ir skaitliska vērtība - 1234567890. Loģiski, ja datubāzē datums ir formātā '2014-12-29 11:10:01' un tu select šādu strtotime vērtību, tad LIKE sanāk %1234567890% kas nekad neatbildīs. Pareizi ir $date = new DateTime('2014-12-29'); $from = $date->format('Y-m-d 00:00:00'); $to = $date->format('Y-m-d 23:59:59'); [...] WHERE `date` BETWEEN '$from' AND '$to' // also, izmanto PDO/MySQLi un :params

Exactamente. Par ko pamatā ir visa šī diskusija.

Tu gribi teikt, ka multidimensionālu masīvu sintakse PHP ir adekvāta? $config = Config::wat(); $config['key']['wat']['batman']; Paglābj vienīgi varbūt dot syntax, Config::get('dot.syntax.wat.batman');

Tā (ne)darbosies validācija tikai 1 līmenī, konfigurācijas struktūra parasti ir vismaz 2 līmeņi. Interfeiss nekādā veidā nepalīdzēs enforsēt shēmu. Nav pat tādas vajadzības. Ja viens avots, tad viens avots. Ja ielādēšana katru reizi ir par lēnu, konfigurāciju glabā PHP un izmanto opcache. Go home, troll. Scala is irrelevant and gay. @Briedis es tev pilnīgi piekrītu, taču problēma šeit tāda, ka atkal, single level. Ide tev nepateiks priekšā masīva saturu. Ja, piemēram, JS mēs varam pateikt ka { foo : { bar: [] } } un IDE to pat atrisinās, tad PHP tādas konstrukcijas vēl diemžēl nav.

Paldies par ieteikumu! Būs jāpalūko, kas tie tādi freimworki par zvēriem. Nekad iepriekš nebiju dzirdējis. >:( ...

Papildus dažas problēmas ar konfigurāciju, par kuru risinājumiem vēl neesmu pārliecināts: shēmas konfigiem (domā, man vajag lai x saturētu masīvu ar skaitļiem, nevis masīvu ar būliem) un normāls konstrukts, kā šo konfigu lasīt.

Izlasi taču manu komentāru. Es runāju par kaut ko pilnīgi citu.

Es runāju par kaut ko citu. Ilustrēju problēmu: <?php namespace Config { // Prod class ConfigFooBar() { const x = 1; } // Dev, citā failā, obviously class ConfigFooBar() { const x = 2; } } namespace Blah { use Config; class MyClass { $x = ConfigFooBar::x; // Nemutējama statiska reference // Autoloader eksplodē liesmās } } Kuru no ConfigFoobar ielādēs PSR? To, kurš ir attiecīgajā namespace failā. Lai to novērstu ir jāveido divi faili, katrs savā namespace/direktorijā. Tad vēl ir sintakse $foobar::x, un tad varētu typehintot, bet tas nemaina faktu, ka nepieciešams papildus autoload un pieeja pēc name piedrazo scope ar daudz mainīgajiem. Šī pieeja nav īsti ne ar ko labāka par imutējamu konfig konteineri kā servisu vai di. P.S. Es tagad iedomājos arī par spec/unit testiem. Well...

Tas ir pašsaprotami, bet tā darot zaudē PSR autoload un jāpieraksta savs, kas ielādēs konfigus atkarībā no vides. Bet tad mēs zaudējam inheritance un autocomplete būtu tikai ar type hintiem.

Pieliku listē. Bet no otras puses, šis liekas itkā hardkodētu immutējamus konfigurācijas objektus, kas neliekas pareizi. Bet vai tam vispār ir nozīme?

Miljards gadus vecs topiks, bet nule atkal kļuvis aktuāls. Domāju un nevaru izdomāt, un šeit nu ir saraksts ar visām opcijām, kas vien ienākušas prātā. PHP masīvi failos <?php return [ 'a' => 1, 'b' => 2 ]; Pros: Smieklīgi fleksibls (tas ir PHP fails, duh) Opcached Dikti ātrs Cons: Nolāpītie masīviJSON { "a": 1, "b": 2 } Pros: Vari dalīties ar konfigiem offline ar citām platformām (kura gan neatbalsta džeisonu?) Diezgan viegli lasāms Cons: Lēnāks Diezgan tizli rakstāms YAML --- a: 1 b: 2 Pros: viss, kas JSON + vēl vieglāk lasāmsCons: Lēns kā sunsINI [config] a=1 b=2 Pros: ātrāks par JSON un YAMLCons: tikai 2 līmeņiPHP objektu konstantes <?php class Config_Foobar { const a = 1; const b = 2; } Pros: nav tika fleksibls, kā PHP masīvi - tikai konstantas vērtības opcached dikti ātrs tu vari izmantot autoload IDE autocomplete Cons: konstantas vērtības (moš tas ir labi?) viens līmenis (izņemot, ja tu esi lielisks un lieto 5.6, tad tu vari tur iebāzt arī masīvus) Ja 5.6+, tad mans personiskais favorīts. PHP Objektu statiski propi Tas pats, kas konstantes, tikai tupāka sintakse un nevajag 5.6. Thoughts? Konstruktīvas idejas?

Izbaudi dzīvi. Aizbrauc uz folk ralliju un izārdies. :)

gurkjis,