2lips.pl – pasja programowania

Korzystacie z Propela i przeszkadza Wam jego inspirowane Javą Criteria api? Otóż jest proste rozwiazanie – sfPropelFinder napisany jak nazwa wskazuje pod framework Symfony, ale można go z powodzeniem stosować bez samego frameworka! Instalacja dostępna przez PEAR’a, a sztuczki jakie można za pomoca tego plugina realizować niektórzy porównuja do tych znanych z jQuery.

Parę przykładów z Fligga:

• pobierz listę głosów dla linku i użytkownika (link)
• pobierz liczbę głosów na dany komentarz linka (dla danego użytkownika) (link)
• wybierz moduł po nazwie (link)
• zmień status grupy linków (link)

Jak coś przybędzie to napewno tutaj dopiszę.

Jednym z założeń projektu Fligg jest niezależność od konkretnego silnika bazodanowego, a narzędziem które ma to  umożliwić jest Propel – ORM php’owy (od wersji 1.3 korzystający z PDO). W dokumentacji pisza, że wystarczy sobie skonfigurować poprawnie bazę, dopisać parę linijek konfiguracji dla phinga i gotowe. Rzeczywistość przedstawia się nieco bladziej i żeby zmusić taska phingowego do wygenerowania tego co chciałem musiałem sie sporo namęczyć, no ale koniec końców, działa tak jakbym chciał – tzn. na podstawie xml’owego opisu bazy danych generuje implementację dla każdego skonfigurowanego silnika bazowanowego, a następnie podczas wykonywania dodaje odpowiednią ścieżkę do include_path (w celu include’owania klas wygenerowanych dla właściwego silnika). Skrypt bash’owy generujący implementację można sciągnąć tutaj – warto chyba w tym miejscu nadmienić, że build phing’owy obslugujący całe to ustrojstwo przychodzi  razem z Propelem i po instalacji przez PEAR’a można go znaleźć w katalogu: $PEAR_PATH/data/propel_generator/pear_build.xml lub build.xml (starsza wersja).

I tak oto dochodzimy do problemów jakie się pojawiły po odpaleniu genratora kodu dla Oracle’a.

1. Pierwszy problem dotyczył identyfiaktorów. Niby nic wielkiego, nazwy kolumn i tabel przy wypełnianiu bazy są wprowadzane małymi literami, a podczas wykonywania kodu wszytkie stałe  (z klas *Peer) operujące na identyfikatorach wielkimi, więc żeby sobie uprościć życie dodałem strToUpper tu i tam i problem zniknął.
2. Druga sprawa to format daty. Po instalacji 10g-xe na moim linuchu, domyślny format to DD-MON-YY, czyli jak na przenośny kod dość nieciekawie. To można oczywiście zmienić, ale żaden ze sposobów podpowiadanych przez gugla nie zadziałał, więc pozostało mi to zmienić po stronie aplikacji – tak też się stało. Zaraz po połączeniu, w przypadku wykrycia, że jesteśmy pod Oracle’m wykonywanie jest zapytanie:ALTER SESSION SET NLS_TIME_FORMATA format pochodzi z pliku konfiguracyjnego (kod dostępny tutaj).
3. Ostatnim problemem typowo Oracle’owym, jest dodawanie aliasu w przypadku zapytania zliczającego rekordy (COUNT), otóż jest on najzupełniej  zbędny.

I tak dochodzimy do ostatniej części tego wpisu, czyli sposobu w jaki Propel żongluje kodem odpowiedzialnym za współpracę z konkretnym slinikiem bazodanowym. Domyślnie parametry połączenia są zapisywane do pliku konfiguracyjnego (propel-runtime.php), a Propel podczas inicjalizacji połączenia je sobie wczytuje, co jak się domyślacie wcale nie ułatwiło mi zadania, gdyż potrzebnowałem sposobu na wygenerowanie konfiguracji Propel’a podczas wykonywania programu i przekazania jej do niego, najlepiej w formie tablicy. Tak też zrobiłem, wymagało to drobnych zabiegów w interfejsie Propel’owym, ale działa bez pudła  (metoda initFromArray):)

Wiem, wiem o tym jak dodać paczkę debianową oracle 10g xe, jest aż nadto. Instrukcja instalacji rozszerzenia PDO_OCI też nie jest skomplikowana (Ci którzy instalowali mysql’a z paczki repozytoriów musza usunąć PDO mysql’owe i dodac to dostarczane przez pecl’a). Wpisujemy php -m i dostajemy PDO_OCI na liście zainstalowanych modułów, odpalamy skrypcik z wiersza poleceń i wyglada na to, że wszystko jest cacy…

…problem pojawia się jak chcemy ten sam skrypt odpalić za pośrednictwem apache’a

Mnie Xdebug nagrodził błędem:

Unable to open PDO connection [wrapped: SQLSTATE[]: pdo_oci_handle_factory: OCI_INVALID_HANDLE (/tmp/pear/temp/PDO_OCI-1.0/oci_driver.c:463)]

Pierwszy strzał to dodanie zmiennych środowiskowych ORA*, no ale to nie pomogło, później to samo dla użytkownika www-data, też nic, aż w końcu wyguglałem, że trzeba zmienne środowiskowe dopisac do pliku konfiguracyjengo apache’a (ustawianie ich w trakcie działania nic nie daje), no więc poniżej moja konfiguracja:

marek2@marek-laptop:~$ cat /etc/apache2/envvars
# envvars – default environment variables for apache2ctl# Since there is no sane way to get the parsed apache2 config in scripts, some
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
export ORACLE_SID=XE
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
export ORACLE_OWNER=oraclexeexport APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2.pid