Kāpēc pēc nl2br() paliek n zīmes?

[root]

ĻŠŒĻ, you funny guy 😀

Kā tas ir nevar insertot “datu grupas”? 😀 Kam tad domāts PDO prepared statements un tranzakcijas?

Pseido:

Code:

dbl->beginTransaction
statement = prepare(query)
foreach(items as item)
{
statement->execute(item->id,item->name,item->whatever)
}
dbl->commit

Un PDO nav tas pats, kas ar roku rakstīts SQL. Jo dziļāk mežā jo vairāk koku- ieskaties PDO draivera un SQL DBA arhitektūrā, lai iegūtu vairak informācijas.

Par pārējām muļķībām, ko tu te sadrukāji es nemaz neizteikšos.

[natolv]

Vispār jā – sori, pats sajaucu!

[Crow]

Kaut jūs visus betons izdrāztu.

Prepared statements ir elementāra drošības prakse. Pirmais, ar ko paņem priekšā visus šitos lielos meistarus – SQL injections. Mazā websūdā, kur viens pats ņemās, var cerēt, ka izdosies izķert visus injekciju vektorus (bet prakse liecina par pretējo, tak superglobals pat ieslēdz atpakaļ, jo lūk vecais kods nejiet), bet kur strādā divi vai vairāk (un kā likums, penetration testing tiek uzmīzts, jo visi tak ir profesionāļi) – katastrofa, kas tikai gaida, lai notiktu.

Prepared statements pēc būtības nepieļauj notikt SQL injekcijai – komandu vienreiz (un tikai vienreiz) kompilē uz SQL komandām klients un dati tiek padoti binārā formā (nevis teksta), tai skaitā string vērtības. Nav svarīgi, cik reizes – nevienu, vienu vai divsimt. Kā arī eskeipošanas overhedu varam atrēķināt – palicis tikai uzmanīties neizvadīt pēc tam nevietā.

Attiecībā uz muskuli – obligāti MySQLi. PDO ir derīgs tad, ja zināms (vai pretēji – absolūti nav paredzams), ka vajadzēs suportēt arī citas DBMS.

Cik prātā kroplim jābūt, lai par to vēl diskutētu… meistari, bļeķ. Pasniedzējs, hrrr – kas pats nevar, tas māca citiem.

[root]

Paļauties uz prepared statements kā uz “drošības praksi” var tikai ļoti tuvredzīgs “meistars”, kurš nekad nav dzirdējis par otrās kārtas SQL injekciju jeb reversām SQL injekcijām, kā arī nav dzirdējis par to, ka prepared statements nevar argumentēt identifikatorus, kas rada “viltus” drošības sajūtu tiem, kas ar to nav saskārušies – piemēram, tabulu un kolonnu nosaukumi dažreiz var tikt konkatenēti tieši vaicājumā (liels procents jauno programmētāju nesaprot, ka konkatenēšana vaicājumā PDO nedarbojas tā pat, kā argumentācija) kas savukārt, netiek filtrēts. Aizsargāties pret visiem SQL injekciju “vektoriem” var bez PDO, tas tiek efektīvi darīts jau labi sen un PDO prepared statements uzskatīt par “drošības līniju” pilnīgi noteikti nevar. Uz to paļautos tikai nekompetents stulbenis.

Pie reizes, šeit nonākam arī pie garbage in – garbage out principa, ko itin viegli iespējams palaist garām, aka – 1 ievade un 20 izvades, 19 izfiltrē un 1 ne. Rezultāts ir reversa sql injekcija vai klienta puses injekcija.

Therefore, fuck you. Normāli cilvēki paplašina noklusējuma PDO un MySQLi ar savu funkcionalitāti vienalga iepriekšfiltrējot visus ievades datus gan pret reverse sql, gan pret klienta un servera puses koda injekcijām.

Un nemaz neaplūkosim gadījumu, kad PDO/MySQLi vai citā prepared statement dzinī ieviesīsies kāds kukainis, kas padarīs visu tavu, faktiski, viena slāņa datu filtrāciju kaķim zem astes metamu. Double the gun, double the fun.

Pie tam, daudz labāks risinājums tiešam PDO/MySQLi ir ORM, kur datiem tiek piemēroti filtri atkarībā no shēmas specifikācijas un lietotāja validācijas noteikumiem.

Also, PDO lietot lai supportētu citas DBVS ir ļoti muļķīgs pasākums – jau zināms, ka kaut cik nopietnai aplikācijai vienalga 50+% nāksies pārrakstīt, bet nenopietnai nekad nenāksies migrēt uz citu DBVS. Fakts. Tāpēc, atkal, normāli cilvēki izmanto atsevišķus natīvus draiverus un wrapperus ar predefinētu abstraktu funkcionalitāti kas implementē DBVS specifisku funkcionalitāti, kas migrācijas gadījumā būtu replicējama citai DBVS izmantojot tos pašus funkciju saucienus tikai savādāku bāzes klasi. Mazliet abstrakcijas, bet pieļaujami.

Par MySQLi atliek vien piektrist. ~2-3% ātruma augums vienalga ir ātruma augums. 🙂

Bet jāmācās tev puisīt, vēl daudz jāmācās. Esi domājis apmeklēt LTTC kursus pamatskolniekiem? 😀

[natolv]

Nezinu, ko visi strīdas, bet nu – 1. teikums iekš php.net visu pasaka!

The PHP Data Objects (PDO) extension defines a lightweight, consistent interface for accessing databases in PHP.

https://www.php.net/manual/en/intro.pdo.php

[Crow]

Varbūt tu savā Maskačkas pagraba ūķī, brīnumbērns Ērik, vari viens pats visu kādu sistēmu cept no nulles un tad garantēt klientam 100% bug-free, bet tiklīdz jāstrādā vairākiem pie vienas sistēmas, un tad parasti tuvredzīgo komandā netrūkst (kā likums, ja neviens cits, tad tas būs vismaz projekta vadītājs) – nevar galvot par absolūti neko. Nu neiet krastā uzbāzties citam ar savu “vienīgo pareizo variantu” vai vispār bāzt degunu cita darbā, kad katram jādara savs darbs ir un pēc iespējas ātrāk.

Oh wait. Ja varētu garantēt tādu 100% bug-free, jau pašos pamatos nemaz nebūtu jāstrīdās par risinājumiem.

Prepared statements ir pirmais solis, nevis pilnvērtīgs risinājums, uz kuru jāpaļaujās. Datu validēšanas nepieciešamību tas neatceļ (uzsveru un pa zilbēm: ne-at-ceļ), tikai padara to stipri vienkāršāku. Tas pavisam noteikti ir drošāk kā paļauties uz kāda pārgudra mozgojobaka (kurš pie attiecīgās sistēmas nestrādā vismaz daļēji tieši dēļ tā, ka bija tāds pārgudrs mozgojobaks) saceptajiem wrapperiem – un tos katrs cep pēc sava prāta, liberāli pārkaisot ar, PHP gadījumā, addslahes UN real_escape_string UN htmlspecialchars un, nedo dies, regexp, un dažkārt vairākreiz, jo tak “dubults neplīst”). Un tad cilvēkam jāpaļaujās uz tādu kišmiš ar sūdbumbuļiem? Ej tu nost!

Vari nedirst par kvazistacionāro pipelizatoru antimorfoloģisko kokteilēšanu iekš PDO vai citur (jā, internetā uzvar tas, kam “lokanāka klaviere”, mhhh) – to atstāj saviem iedomu Ērikiem. Varētu teikt, ka tāds pats kā betons – pļurkst kā Iža motors bez aķa, bet grieziena nav. Pag, nē, betons vēl nav atvēris savu iedomu institūtu un nepasniedz rūteru lodēšanas lekcijas…

[Inspektors_Caps]

root,

Quote:

Labāk, protams, izmantot parametrizētu single instnce vaicājumu, bet SIQ nav prepared statements.

Runa arī bija par parametru bindošanu, tikai linku iemetu uz prepared statements, jo tur ir labs piemērs bindošanai. Un izskatās, ka arī Crow, kā viens no retajiem, kas īstenībā rubī fišku, būtībā runā par parametru bindošanu, nevis prepared vai single instance izpildi.

Un tagad pa īstam…

Quote:

Rekomendē lietot abstrakcijas slāni datubāzēm un demagoģē par veiktspēju, skeilojamību un vienkāršību. Stulbenis.

Tā vietā, lai serverim nosūtītu konkatenētu stringu ar SQL natīvu komandu, tiek nosūtīts strings bez vērtībām, pēc tam tas izpārsēts, piešķirtas vērtības un pēc tam izpildīts.

Atliek vien citēt:

Quote:

Pērle. Pērle no pērlēm. … Ä¢eniāli. Sēdies, puisīt. Būtu mans students, ieliktu 2.

Tieši nevis bindošana ir abstrakcija, bet gan stringu konkatenēšana. Natīva SQL komanda? Kam tā ir natīva? Cilvēkam! SQL ir cilvēkam lasāms teksts, nevis bināras komandas vai dati datoram. Turpretī parasts mainīgais ir bināri dati, kas ir natīvi datoriem abos galos. Paskaties par piemēru kaut vai visparastāko 32-bit signed integeri. Līdz 11 simboliem/baitiem (10 cipari + zīme) plus formatēšana vienā galā un parsēšana otrā. Bināri turpretī tie ir tikai 4 baiti, kuri nevienā galā netērē lieku CPU un RAM ar liekām pārveidošanām uz/no nevajadzīgā cilvēkiem lasāmā formāta, par lielākiem un/vai sarežģītākiem datu tipiem nemaz nerunājot… Ja Tu šo nesaproti, tad ir tikai nožēlojami, ka, līdzīgi kā daudzi pasniedzēji, esi abstrahējies tik tālu no realitātes un pamatvērtībām savā teorijā, ka vairs pat nesaproti ko pats nesaproti!

Runājot par to, ka parametru bindošana WEB izstrādē neatrisina visas injekciju problēmas – tas, ka HTTP, HTML un lielākā daļa citu WEB tehnoloģiju ir ievainojamas, totāli nepārdomātas un vispār debilas pamatā atkal dēļ tā, ka ir uztaisītas natīvi lasāmas cilvēkam nevis datoram, neattaisno nepareizu datu bāzu programmēšanu. Ä€rpus līkajām WEB tehnoloģijām arī spēj padomāt? Nu un kaut vai WEBā pārbaudi, ko laid iekšā un/vai ārā, bet parametri tāpat jābindo! Un te nu tiešām ir PUNKTS jeb kā Crow teica:

Quote:

Cik prātā kroplim jābūt, lai par to vēl diskutētu…

Ak, jā…

Quote:

Un nemaz neaplūkosim gadījumu, kad PDO/MySQLi vai citā prepared statement dzinī ieviesīsies kāds kukainis, kas padarīs visu tavu, faktiski, viena slāņa datu filtrāciju kaķim zem astes metamu. Double the gun, double the fun.

Kāda ir varbūtība, ka būs kukainis desmitgadēs pārbaudītā dzinī, un kāda, ka Tavā vai Tava studenta “pointeri man par sarežģītu – tādēļ kodēju weblapas, kas piektdien jānodod” kodā? Un kā apiesi SQL parsera bugus tajā pašā DBVS?

[root]

Nezinu, smieties vai raudāt. Diez kur paliek šitādi crowi un inspektori šminspektori kad kaut kas reāli jāveido, vienalga – web vai ne web? Nu tā, lai savus murgus pārbaudītu arī praksē, ne iedomās, savos tukšajos pauros. Maģistri, šmaģistri.

[Crow]

Viņi, nolādētie Vella kalpi, izpilda Sātana kārās iegribas, viņi kāro pēc jūsu dvēselēm, viņi… ***

Viņi apsmej jūsu šķīsto ticību!

[root]

Jā, un kāda ir varbūtība, ka Leonardo DaVinči koka tanks nebūtu efektīvs kaujas assets 21. gadsimtā? Jā, kas gan varētu notikt ar 10 gadus pārbaudītu sistēmu, tik tiešām…

Jibio, tev taču ne pointerus vajadzētu stumdīt un ar atmiņas menedžmentu nodarboties, bet lāpstu pagalmā operēt. Vai nezinu, piesakies VARAM vai kādā citā valsts darbā. Iederēsies. 🙂 Un kafiju man atnes, pie reizes…

[Inspektors_Caps]

Nu, nu, kā iebāza maisā, tā sākās tukša un nepamatota bezsakara gvelšana? Vēl mētā te kaut kādas PHP komponentes kā baigos industrijas piemērus. Un Tavā “čerez string visu muļļāju” stratēģijā pa vidu ir par diviem liekiem programmatūras jeb potenciālu bugu posmiem vairāk. Konstanta izmēra 4 baitu pārkopēšanu tā kā būtu vieglāk/ticamāk uzrakstīt bez bugiem kā divas int2str un str2int funkcijas! Vispār Tev kā mācību spēkam īpaši bija vairāk jāatbalsta korekti risinājumi un jāmāca darīt pareizi, nevis tas kā līku sistēmu, salipinot ar citu līku sistēmu, var dabūt, ka Tev un studentiem izskatās ka strādā!

Kur viņi paliek? Viņi izstrādā embedded sistēmas, draiverus, protokolu parserus (arī debilu human readable), arī elektroniku un citas lietas, kas nedrīkst kārties un gļukot, un viņiem “ne līdz” kaut kādiem ķep ļep risinājumiem. Bez tā visa bieži vien kaut kādai līkai PHP drazai nemaz nebūtu jēgas. Pie reizes, protams, varu atnest arī Tev kafiju, bet, kad nākošreiz taisi sev kafiju un man tēju, atceries – tēju dzeru bez cukura, lai izjustu garšu! 😉

Labi, štrunts ar visu pārējo, bet Tu (īpaši kā mācībspēks) bez tukšmuldēšanas pamato mums pašu lielāko savu glupību un galveno šajā diskusijā – kādēļ integer vai cits mainīgais Tavuprāt ir jāpārformatē uz tekstu, jāpārraida lielāks un otrā galā jāparsē atpakaļ?

[piwchix]

Nu razveļi tut soru 😀

Es vēlreiz atkārtoju, nav viena pareizā pieejas varianta nekur. Nepisīsim prepared-statements vizītkartes lapai vai vienam sūda UPDATE kverijam, neparticionēsim tai vienīgo NEWS tabulu, kuru labo admins reizi pusgadā, neindeksēsim n-fieldus, netaisīsim veselu DB layer klasi vienam vienīgam kverijam, nepirksim šai lapai i7 fizisku serveri utt. utjp. Nevajag stiept savu ticību tur, kur nevajag. Varbūt tusnīsim 3 gadus prastu lapu binārkodā?Nē?Kāpēc PHP ne Python?A kāpēc MySQL ne piem. Oracle?Jūs arī noteikti zinat vislabāko GPU/CPU ražotāju, OS, mobilo telefonu, web pārlūku, auto, brokastu pārslas, alus marku…. utt.?

Tāpēc pasaulē ir tik liela dažādība JEBKUR.

NAV un NEBŠªS viena risinājuma visam. PUNKTS.

[aoma]

Acīmredzot taisnība vecajam sakāmajam ir – tie, kam neizdodas savā nozarē neko prātīgu sasniegt, dodas strādāt par pasniedzējiem 😀

[root]

Lai “iebāztu mani maisā” tev vēl jāaug garā un prātā.

Valdot smieklus par embedded sistēmu, draiveru un protokolu izstrādi. Wow. Nu ļoti iespaidīgi. 1. kursa studentam, ne man. Varbūt vēlies man arī kādu kerneli nokompilēt ar kādu pašrakstītu custom moduli? 😀 Bet piemīlīgi indeed. Es un tādi kā es savukārt uz doto brīdi raksta SPI un veido SPI arhitektūras, tajā skaitā programmatūru – sākot no blackboard līdz produkcijai un visādas citas interesantas lietas, piemēram, auditē un sviež atpakaļ tādu gudrinieku, kā tu, sastrādātos mēslus.

Ja tu, tupais radījums, izbāztu savu tukšo pauri ārā no alas, kur tu sēdi, un kaut nedēļu pavadītu pie praktiskas web programmēšanas, PHP vai ne PHP, whatever, un nedaudz lielāka projekta par tavas mātes recepšu vācelīti, tev būtu skaidrs, ka realitātē aplikācijas komunikācija ar datu bāzi nenotiek kā matriksā – svaidoties ar vieniniekiem un nullītēm, >90% gadījumu “mainīgie” jau satur tekstu – string tipa kvalitatīvu vērtības. Realitātē, 85-100% operāciju, kas tiek izpildītas pret datu bāzi ir CRUD lietotāju ģenerēti dati, no kuriem, kā jau minēju, >90% ir teksts. Tagad tu man pastāsti – kapēc pielāgot sistēmu 10% un muļļāt atlikušos 90? Varbūt savās īsajās darba gaitās esi dzirdējis par terminu – pāroptimizācija? Konkrētajā gadījumā, es nevienā vietā neesmu teicis ka PDO būtu slikts, vai ka prepared statements būtu slikts. Ja tu vari atrast šajā topikā tādu rindu – go ahead. I dare You to. Ja pacentīsies vēlreiz izlasīt ko saku, tad atradīsi –

root wrote:

Vaicājuma konkatēšanai nav ne vainas, ja netiek apstrādāts batch. Labāk, protams, izmantot parametrizētu single instnce vaicājumu, bet SIQ nav prepared statements.

Š ajā gadījumā, ieguldīt uz pusi vairāk darba lai nodrošinātu, faktiski, to pašu funkcionalitāti ar 0.000X% veiktspējas augumu vienkārši nav jēgas. To darīt ir jēga, ja tava lapele ir deployota uz vismaz padsmit platformām un tiek balansēta savā starpā. Taču labs programmētajs jau iepriekš zina katras aplikācijas potenciālu un iegūlda izstrādē attiecīgu darbu un optimizācijas līmeni, lai iegūtu izdevīgu rezultātu. Katram uzdevumam ir savs QA līmenis. Tu varbūt arī esi lielais valis savā spainī, bet vienalga – spainī.

Savas no mācību grāmatas izvilktās atbildes paturi pie sevis. Manos ikdienas plānos neitilpst vēlme izglītot pārgudrus visziņus interneta ārēs, kas dienas beigās vienalga nesapratīs par ko tad īsti šajā topikā ir runa.

P.S. PHP mysql “natīvās” funkcijas jau labu laiku ir deprecated. Use of MySQLi or PDO is encouraged. 🙂

[root]

Tādā gadījumā, tev jau sen vajadzēja būt divkāršam profesoram.

[root]

Lai pārtrauktu stulbuma lavīnu pret manu pasniedzēja darbību – es vienmēr un primāri esmu bijis praktiķis un tikai pēc tam pasniedzējs. Nevienu brīdi neesmu pārstājis praktizēt savu darbu lai pasniegtu. Patiesībā otrādi – esmu pārtraucis pasniegt, jo ir vairāk darba, kā paredzēts. Kaut kā gluži nesaskan, ne?

[aoma]

Labprāt, tikai Latvijā diemžēl nozare, kurā mācījos, vismaz 20 gadus vairs nepastāv, tā ka nākas vien strādāt un priecāties, ka gluži visu vēl aizmirsis neesmu 🙂

Un būt par pasniedzēju nav stulbums, tā ir diagnoze.

[Nelabojams]

No konkrētās tēmas neko nerubīju, bet gribu par pasniedzēja darbu.

Mana attieksme un pieeja ir apmēram tāda pati kā tavējā. Vēl vairāk – es darbojos tādā diezgan neapgūtā lauciņā un, stāstot par šīm lietām studentiem, pašam lekciju laikā uznāk atskārsme par šo to, kā to izdarīt labāk vai pat labāka izpratne par kaut ko.

No otras puses, kad esi izstrādājis ko interesantu un, vēl jo vairāk, pārbaudījis praksē, tad ir tāda milzīga nieze kādam to visu izklāstīt un redzēt, ka viņš saprot un pratīs to izmantot – tā ir pavisam cita sajūta, nekā, piemēram, sausu publikāciju iedabūt iekšā prestižā starptautiskā žurnālā.

Tā ka nav te ko dažiem aplikt pasniedzēja darbu – ja nu vienīgi esi sevi izsmēlis, neaudz savā profesijā un strādā tikai naudas dēļ, ne sevis paša priekam.

[Inspektors_Caps]

Oj, nu, root, baigais specs Tu mums esi – baigi “izcelies” uz kopējā pelēkā biznesa sistēmu izstrādātāju fona! 😉 Tieši kaut kādu HTML un PHP smērēšana ir atbilstoša pirmā kursa studentam, nevis nopietnas sistēmas. Ja pareizi saprotu, Tev ir stabils darbs pie vienādu stabili garlaicīgu biznesa sistēmu izstrādes, jo Tu jau atkal plāties ar saviem “īsto veču” webbumbulīšiem. 😀 It kā inteliģents cilvēks izklausies, bet šobrīd Tev līdz OS kernelim un domāšanai, kāda nepieciešama kernel space izstrādei, ir tālāk kā līdz Mēnesim. Nākošreiz, kad milisekundēs ABS vai ESP kārtējo reizi izglābj Tavu pēcpusi, kad Tev tuvu cilvēku, neuzkaroties ne uz milisekundi, uztur pie dzīvības kāda medicīnas iekārta, vai, kad vienkārši lasi par Marsa izpēti ar Curiosity rover, tad atceries, ka tās sistēmas izstrādā tādi kā es. 🙂

Quote:

realitātē aplikācijas komunikācija ar datu bāzi nenotiek kā matriksā – svaidoties ar vieniniekiem un nullītēm, >90% gadījumu “mainīgie” jau satur tekstu – string tipa kvalitatīvu vērtības. Realitātē, 85-100% operāciju, kas tiek izpildītas pret datu bāzi ir CRUD lietotāju ģenerēti dati, no kuriem, kā jau minēju, >90% ir teksts. Tagad tu man pastāsti – kapēc pielāgot sistēmu 10% un muļļāt atlikušos 90?

Nu vot izbāz savu tukšo pauri ārā no savas web-alas un apjēdz vienreiz, ka galā datu bāzē viss vienalga tiek apstrādāts un glabāts optimālajos formātos – bināri! Arī Tavā teksta muļļāšanas scenārijā formatēšana un parsēšana NOTIEK, tikai Tu savā “labajā” risinājumā to esi pārmetis no klienta uz serveri, plus papildus krietni vairāk nevajadzīgi noslogo tīklu.

Quote:

Vaicājuma konkatēšanai nav ne vainas, ja netiek apstrādāts batch.

Ir gan vainas, un nopietnas, pie tam visas novērš bindošana.

1. Ievainojamība tieši attiecībā pret SQL sintaksi.

2. Vismaz uz konkatenēšanas brīdi RAM ir jāizveido jauns strings.

3. Stringu kopēšana/savienošana prasa vairāk CPU jaudas kā bināru datu.

4. Potenciālas formātu nesakritības problēmas, piemēram datumiem ar dažādiem reģionālajiem uzstādījumiem.

Quote:

Š ajā gadījumā, ieguldīt uz pusi vairāk darba lai nodrošinātu, faktiski, to pašu funkcionalitāti ar 0.000X% veiktspējas augumu vienkārši nav jēgas.

Pirmkārt, negriez visu otrādi – bindojot mainīgos, darba ir krietni mazāk! Pati bindošana, ja salīdzina ar stringu savienošanu, prasa apmēram tik pat daudz koda, bet toties ir krietni mazāk koda un domāšanas par formatēšanu, plus pilnībā atceļ nevajadzīgās eskeipošanas un injekciju pārbaudi uz tieši SQL sintaksi.

Otrkārt, ja spēj novērtēt visu sistēmu kopumā, nevis kāda viena atsevišķa posma darbību starp citiem bremzētiem posmiem, tad te vairs nav runa par 0,0..% bet gan procentiem, ko raksta ar diviem cipariem pirms komata!

Rezumē – tā nav pāroptimizācija, bet vienkārši lieka un problēmas radoša darba nedarīšana.

P.S. piwchix ir kā tipisks root students – nespēj pat atšķirt vienādu lietu niansēs atšķirīgas realizācijas no fundamentāli dažādām pieejām.

[root]

Labi, tev ir taisnība. Es esmu muļķis, un runāju muļķības. QA auditori un OSE komūna pēdējos desmit gadus arī ir idioti un pilnīgi noteikti nejēdz, ko runā. Imho senior software (ne tikai web) un systems development specialist man posā ne vienu reizi vien ielikts par skaistām acīm. Tikai tu viens, marsa izstrādātājs ibio, saliec bumbierus ar zaķa spirām un uztaisi konfekti. Bravo.

Quote:

Nu vot izbāz savu tukšo pauri ārā no savas web-alas un apjēdz vienreiz, ka galā datu bāzē viss vienalga tiek apstrādāts un glabāts optimālajos formātos – bināri! Arī Tavā teksta muļļāšanas scenārijā formatēšana un parsēšana NOTIEK, tikai Tu savā “labajā” risinājumā to esi pārmetis no klienta uz serveri, plus papildus krietni vairāk nevajadzīgi noslogo tīklu.

Jā, bļin. Pastāsti man vēl par SE un shēmām. Klients maģiski teleportējies ārā no servera skopes, nd/nnd vairs maģiski vērtības neapstrādā un ļauj tik barot iekšās visu, kas ienāk prātā un problēmas pārcelšana no punkta A uz punktu B pēkšņi maģiskā kārtā atrisina visas problēmas. Wow, esi atklājis pirmo universālo un vienmēr korekto atbildi uz senu programmēšanas jautājumu.

Marš lasīt mysqlnd un mysqld sources. Cerams, ka ekstensīvās zināšanas pointeru operācijās tev ļaus saprast tik primitīvu kodu. Es savukārt pat nafig vairs neatbildēšu uz tavu stulbumu.

[Autors]

Ieraksti