Jump to content
php.lv forumi

marrtins

Reģistrētie lietotāji
 View Profile  See their activity

  • Posts

    1,570

  • Joined

  • Last visited

 Content Type 

Posts posted by marrtins

  1. Mistika ar Sessijas timeout

    in Vispārēji

    Posted

    Es nepaļautos uz gc_*, lai kontrolētu precīzus sessijas timeoutus. Labāk ievies $_SESSION['started']=time(); un if(time() - $_SESSION['started'] > 3)session_destroy();

     

    Likt session.gc_probability un session.gc_divisor uz 1 ir absurds, sapratīsi, kad būs daudz daudz pieprasījumu sekundē :)

  20. MySQL dīvainības ar mainīgajiem

    in Datubāzes

    Posted · Edited by marrtins

    Nē nu bāc, tas MySQL man sāk tracināt uz šīm niansēm. Praktiski šāda variabļu "fīča" SELECT pieprasījumā sanāk bezjēdzīga. Būs viss jāpārraksta. It kā jau loģiski, ka tā inicializēšanās secība nav definēta, ja darbojas ar kopām, bet nu tad nafig tādi vispār vajadzīgi SELECTā? :E

     

    Atminos, vēl pirms laika, kad šāda tipa nesaprotami MySQL gļuki parādījās pie datubāzes ar procedūrām dump un restore uz citu serveri, kad mysqldump pie procedūras definīcijas piekabināja DEFINER = 'user@host'. Gala serverī tāds users neeksistē, viss saimportējas, bet procedūra nedarbojas un nekādi skaļi paziņojumi par to netiek doti. Kamēr to gļuku atradu... :E

     

    Paldies \m/

  21. MySQL dīvainības ar mainīgajiem

    in Datubāzes

    Posted · Edited by marrtins

    Ja godīgi, maz ko zinu par MySQL mainīgajiem, bet vai šai gadījumā nav tā, ka vispirms tiek izpildīta where klauza un tad tikai iniciēts mainīgais @has_vendor_id.

    Diezvai, jo plain selektā viss rādās "kā vajag", kā arī, selektējot pēc abiem pirmajiem mainīgajiem, arī viss darbojas.

     

    Līdz ar to ir vismaz 2 iespējas, manuprāt:

    1) rakstīt nosacījumu uz individuālajiem mainīgajiem, jo coalesce jau ir tikai f-ja un to var gana viegli nosimulēt papildus where nosacījumos ar mazliet garākiem AND/OR nosacījumiem

    Jā, patlaban esmu izlīdzējies ar šo variantu, bet baisi negribas šo lieko drazu katrā vietā, kur tiek uzstādīti filtri. Protams, var jau ieviest kādu f-iju. Lai nu kā, bet rezultāts ir visai interesants, gribētos zināt kāpēc tā.

     

    2) rakstīt virsselektu, kuram subselekts ir šis te jau dotais (iespējams bez SQL_CALC_FOUND_ROWS, kuru var iznest virsselektā) un where klauzu pielietot virsselektā, kur @has_vendor_id jau būtu jābūt izrēķinātam.

     

    Šis nebūs risinājums jo 1) performance aizies dupsītī 2) pieprasījums jau tā ir visai liels, papildu un papildus sarežģītības slāni negribas ieviest.

     

    Paldies par ātru atbildi!

  22. MySQL dīvainības ar mainīgajiem

    in Datubāzes

    Posted · Edited by marrtins

    Dots pieprasījums (vienkāršots)

    SELECT SQL_CALC_FOUND_ROWS 
@vendor_id:=(<SELECT bla bla LIMIT 1>) AS vendor_id, // INTEGER vai NULL
@has_vendor:=(<SELECT bla bla LIMIT 1>) AS has_vendor, // INTEGER vai NULL
@has_vendor_id:=COALESCE(@vendor_id, @has_vendor) AS has_vendor_id
FROM
_preces

     

    Jebkāda filtrēšana pēc has_vendor_id vai @has_vendor_id NEDARBOJAS.

    WHERE
specid =1191 AND (@has_vendor_id = 2)
----
WHERE
specid =1191
HAVING
has_vendor_id = 2

     

    Savukārt, pēc katra individuāli DARBOJAS

    WHERE
specid =1191 AND (@vendor_id = 2)
---
WHERE
specid =1191 AND (@has_vendor = 2)
---
WHERE
specid =1191
HAVING
vendor_id = 2

     

    Selektā bez nosacījumiem skaidri redzams, ka has_vendor_id aizpildās kā vajadzīgs kā būtu jābūt izmantojot COALESCE. Aizdomas, ka tur kaut-kur pa vidu veidojas BLOB, taču nekādi CAST vai CONVERT arī nelīdz.

     

    Subkveriji šajā gadījumā ir nepieciešami, joinus nepiedāvāt.

     

    Idejas? :O

×
×
  • Create New...