Posts tagged ‘propel’

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):)