Dzisiaj, po czterech wersjach RC ukazała się finalna wersja PHP 5.3.0. Wnosi ona stosunkowo sporo nowości w samym języku, ale wciąż zachowuje prawie kompletną wsteczną kompatybilność ze starszymi skryptami. O tym, co się zjawi, napisanych zostało wiele artykułów, również na tym blogu, dlatego skupię się na nieco innym aspekcie - wdrożeniu oraz mniej znanej funkcjonalności.

Jakiś czas temu Mateusz poprosił o parę słów na temat stanowiska do webdeveloperki na maszynie pracującej pod kontrolą Windows. Zagadnienie nie jest takie banalne, na jakie się wydaje, gdyż pierwotnie to systemy Unixowe były projektowane bardziej dla developerów, potem zaczęto myśleć o ZU. Natomiast w przypadku Windows można powiedzieć, że sytuacja była odwrotna.

Sam pracuję pod Windows (z wyboru, nie z przymusu), niektórzy pewnie też próbują; postaram się udowodnić, że wbrew obiegowym opiniom i pod Oknami da się wygodnie kodzić.

Grunt, to odpowiednio przygotowane środowisko, bo łyżeczką jeziora nie wykopie. [;

Problemy społeczności PHP jak i problemy samego języka opisane pokrótce.

Informacja o artykule poświęconym refaktoryzacji kodu.

Osobiste wrażenia po opublikowaniu propozycji zmian dla PHP 6.0.

Jak wygląda życie zwykłego użytkownika Wordpressa…? Otwarcie przeglądarki, logowanie, napisanie notki, publikacja. Zaraz, a gdyby np. skorzystać w tym celu z jakiejś zewnętrznej aplikacji? Owszem, jest tego w pęczki, nie ma sensu wynajdywanie koła na nowo. Jednak protokół, z którego korzystają zewnętrzne aplikacje, może być wykorzystany także w naszych bibliotekach oraz z poziomu samego PHP.

Pomysł na dzisiejszy wpis podsunął mi ^lukjarz. ;]

W aplikacjach internetowych czasami musimy wykorzystać w jednym serwisie wiele baz danych, nieraz nawet wiele różnych baz danych. Mój wpis będzie prezentował proste przykłady użycia wielu baz z wykorzystaniem frameworka Symfony. Dla przykładu użyje bazy danych PostgreSQL oraz ORM Propela 1.3.

W przykładzie wykorzystam 2 tabele: “users” z bazy “db1″ (załóżmy, że to główna bazy serwisu z użytkownikami) i “requests” z bazy “db2″ (baza w której zapisywane są statystyki z żądań do aplikacji). Modele wygenerowane będą dla bazy PostgreSQL. W kolejnym etapie zaprezentuje w jaki sposób można załadować przykładowe dane pochodzące z data/fixtures.

Definiowanie baz w pliku databases.yml

Edytujemy config/databases.yml

all:
  propel:
    class:        sfPropelDatabase
    param:
      classname:  PropelPDO
      dsn:        pgsql:dbname=db1;host=panic user=db1 password=db1
      hostspec:   pgsql
      port:       5432
      encoding:   utf8

  stat:
    class:        sfPropelDatabase
    param:
      classname:  PropelPDO
      dsn:        pgsql:dbname=db2;host=panic user=db2 password=db2
      hostspec:   pgsql
      port:       5432
      encoding:   utf8

Pierwszym krokiem jest zdefiniowanie połączeń do baz danych. Główną nazwę połączenia będzie “propel” a drugą “stat”

Ustawienie pliku propel.ini

propel.database        = pgsql
propel.database.driver = pgsql
propel.database.url    = pgsql:dbname=db1;host=panic user=db1 password=db1

W pliku propel.ini ustawiamy połączenie z główną bazę danych. “propel.database” odpowiada za generowanie kodu SQL dla danych baz, np.: MySQL, PostgreSQL, Oracle. Jeśli chcemy generować SQL dla wybranego typu bazy, to musimy zmienić na odpowiednią wartość. Można to uzyskać z linii koment ustawiajac –phing-arg

Przykład dla MySQLa:

./symfony propel:build-all --no-confirmation --connection=stat --phing-arg="Dpropel.database=mysql"

Przykład dla Oracle:

./symfony propel:build-all --no-confirmation --connection=stat --phing-arg="Dpropel.database=oracle"

Definiowanie tabel w config/schema.yml

Jak w przykładzie z optymalizacją Propela dobrym nawykiem jest rozdzielenie różnego typu struktur na osobne pliki schema.yml. Główną definicja tabel można zapisać w pliku schema.yml a dodatkową strukturę bazy w osobnym pliku, np w pliku stat_schema.yml.

Plik config/schema.yml

propel:
  users:
    id:              { type: integer, required: true, primaryKey: true, autoincrement: true }
    created_at:      { type: timestamp }
    name:            { type: varchar, size: 255 }
    surname:         { type: varchar, size: 255 }

Plik config/stat_schema.yml

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...