A minap komolyan meggyűlt a bajom a Zend_Paginator komponenssel. Egy HAVING utasítással egészítettem ki a Zend_Db_Select-et melyet a paginatornak akartam adni paraméterként, de állandóan arra panaszkodott, hogy ismeretlen oszlopra hivatkozok a having kifejezésben:
SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘c’ in ‘having clause’
Lefuttattam a query-t közvetlenül MySQL-ben, de ott nem volt tapasztalható a hiba, így a Zend Framework kódját és a fórumokat kezdtem el bújni, majd rövidesen rá is bukkantam a megoldásra: [Zend_Paginator] Bug when using complex Zend_Db_Select. A rendellenesség a Zend_Paginator_Adapter_DbSelect setRowCount() függvényében keresendő, mivel ez a függvény már “lebutítva” kapja meg a lekérdezést, amely ekkor már csak egy oszlopot tartalmazhat. Ha nem így történik akkor kivételre fut. Megértve, hogy pontosan mi okozza a hibát elég volt annyit alakítani a kódon, hogy a paginatornak nem az eredeti lekérdezést adtam át, hanem egy butítottat:
// $select1-ben van a komplex lekérdezés
$select2 = $company->select()->setIntegrityCheck(false);
$select2->from($select1, array('COUNT(*)'));
$paginator = new Zend_Paginator(new Zend_Paginator_Adapter_DbSelect($select2));Álljon hát itt ez a bejegyzés, hogy máskor könnyen visszakereshető legyen a megoldás!
A hírhedt 10.5.6-os frissítés telepítése óta küzdöttem egy buggal. Sokáig egyáltalán nem volt egyértelmű, hogy a bugot a Safari okozza, így aztán eltartott egy darabig mire sikerült megoldást találnom a hibára.
Egy webes feladatnyilvántartó (GTD)/számlázó szolgáltatás fejlesztésén dolgozok. A szolgáltatás saját hitelesítést használ és bejelentkezéskor megadható, hogy következő látogatáskor automatikusan léptessen be a rendszer. Ekkor az alkalmazás – jól megszokott módon – a böngészőben, egy cookie-ban tárolja el a felhasználót és a hitelesítési jegyet. A szolgáltatás ezen része már hónapokkal korábban elkészült, sőt belső körökben már egy ideje a tesztelés folyik. Így meglepetésként ért, amikor nagyon ronda – a hitelesítés modullal összefüggésben lévő – hibák kezdtek megjelenni lépten-nyomon.
Az alkalmazást Fluiddal használom és pont a hiba megjelenése előtt jött ki egy Fluid frissítés. Így első körben teljesen triviálisnak tűnt, hogy a fluid okozza a hibát. Rápróbáltam Safarival is, de a hiba itt is ugyanúgy jelentkezett (tudom, tudom same engine). Később valamiért elterelődött a gyanú a böngészőről és a kódban kezdtem el debuggolni, nem túl sok sikerrel. Végül ismét a Webkit-re kezdtem fókuszálni, miután feltűnt, hogy más webes cuccok cookie-jai is eltünedeznek, míg Firefoxszal hibátlanul működik minden. Az Apple fórumán találtam hasonló – cookie elveszéses – hibákról szóló topikokat. Másoknál is jelentkezett ez a bug a 10.5.6-os OS X frissítést követően és többen javasolták a böngésző újratelepítését.
Le is rántottam a Safari (3.2.1) image-et az Apple-től. Feltelepítettem a programot, majd újraindítottam. Azóta kifogástalanul menti a Fluid is és a Safari is a cookie-kat és a szolgáltatás hitelesítésével sincs gond. Süti!
Cirka két estét szúrtam el azzal, hogy egy egyszerű Cocoaban írt példaprogramban megtaláljak egy hibát. Az NSUndoManager-t modellezte volna a példa, de az istennek sem akart működni az undo funkció. Hibaüzenet sem volt így az NSLog-gal kezdtem el kutakodni, majd végül a második estére kiderült, hogy egy egyszerű gépelési hibáról van szó. A legszebb az egészben, hogy azt a bizonyos elütést képes voltam kétszer egymás után elkövetni, mind a header fileban mind magában a metódus definíciójában. Pont azért nem szoktam a header fileból másolás-beillesztéssel átvinni a .m fileokba a deklarációkat, hogy ne essek bele ilyen hibába. Mégis sikerült 
Egyébként az elütés annyiból állt, hogy a
- (void)removeObjectFromEmployeesAtIndex:(int)index;
helyett
- (void)removeObjectFromEployeesAtIndex:(int)index;
került a kódba.
Szép dolog a “key-value” kódolás csak könnyen vezet ilyen hibákhoz.
