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.
- 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ął.
- 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).
- 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):)