Migracje doctrinowe są narzędziem, które ma nam ułatwić wersjonowanie bazy danych. Dzięki nim można po zmianie schematu zmienić zarówno bazę na maszynie developerskiej, a później powtórzyć zmiany na produkcyjnej. Ale to narzędzie ma tylko ułatwić, nie wyręczyć. Wygeneruje klasy migracyjne ale na z góry określonych zasadach. Najpierw operacje na tabelach, później klucze i indeksy:
Niejednokrotnie tworząc bazę danych w MySQL, nie trudno nie zauważyć, iż w świeżej, nieskonfigurowanej instalacji tego systemu zarządzania bazą danych, domyślnym typem kodowania nie jest utf8 tylko cp1252/latin1_swedish.
Tworząc aplikację korzystającą z takiej bazy, a samej używającej unicode, powinniśmy dla świętego spokoju sprawdzić i pilnować z jakiego kodowania nasza baza danych korzysta. Choćby dlatego, że inna aplikacja podłączona do takiej bazy danych może mieć problemy z rozpoznaniem i połapaniem się w tej mieszance kodowań. Nie jest również zbyt intuicyjnym przechowywanie ciągu znaków zakodowanego w unicode, w strukturze używającej cp1252 lub innego systemu kodowania.
Również symfony, z całym przywiązaniem do unicode, nie robi nic, by wymusić stosowanie tego kodowanie w tworzonych poprzez doctrine tabelach, czy też samym połączeniu na lini baza danych - aplikacja. Konieczne jest ręczne ustawienie odpowiednich wartości w pliku database.yml:
all: doctrine: class: sfDoctrineDatabase param: #... attributes: default_table_charset: utf8 default_table_collate: utf8_general_ci
W ten sposób można w spokoju tworzyć aplikacje używające kodowania unicode bez obawy wystąpienia błędu nieprawidłowego kodowania znaków w porównaniu MySQL, lub innych niespodzianek z tym związanych.
Z reguły znaki używane na zachodzie (znaki ASCII) są kodowane w ten sam sposób w unicode jak i w cp1252/latin1, czego nie można powiedzieć o polskich ogonkach, czy występujących w czeskim i innych zachodniosłowiańskich językach ptaszkach (Przykład: Čech).
KomentarzeWczoraj wypuściłem sfForkedDoctrineApply w wersji 1.2.0. Z jednodniowym opóźnieniem, które zostało spowodowane pewną niedogodnością oryginalnej konstrukcji akcji modułu sfApply z sfDoctrineApply.
Dzisiaj Opera Software wypuściła pierwszą, w miarę stabilną wersję Opery na Linuksa, betę 10.53. Prawdę mówiąc, nie mogłem się już doczekać. Działa zauważalnie szybciej, została poprawiona obsługa CSS3, zintegrowana ze środowiskiem pulpitu, i sprawuje się całkiem dobrze jak do tej pory.
Tak się zdarzyło, iż wczoraj swoją premierę miała kolejna wersja Ubuntu, oznaczona numerem 10.4 o dźwięcznej nazwie Lucid Lynx. Przekładając na polski to jasny, przejrzysty lub czytelny Ryś (pozdrowienia dla Ojca). Oczywiście od razu nastawiłem torrenty z wersją biurkową, a po powrocie z pracy, zacząłem sprawdzać zachowanie na komputerach.
Przy okazji przenoszenia dmTagPlugin z powrotem do korzeni Diema, do symfony, przypomniała mi się jedna rzecz, którą warto poruszyć. Dotyczy ona tworzenia behavioura i obsługi pól modelu wprowadzanych przez szablon behavioura do modelu otrzymującego naszego behavioura.
dmTagPlugin zrobił na mnie spore wrażenie, gdy pierwszy raz go testowałem i badałem jego funkcjonalność na potrzeby innej, dość podobnej funkcjonalności z projektu realizowanego w firmie. Wrażenie na mnie zrobił przede wszystkim FCBKcomplete użyty w widgecie, a także w miarę badania, bądź co bądź niedużego kodu, wstrzykiwanie widgetu i walidatora odpowiedzialnego za operacje na tagach do formularza. Bije to inne możliwości tagowania, które widziałem w symfony na głowę.
Dzisiaj postanowiłem, a raczej zrealizowałem postanowienie z tygodnia, by wyjść sobie na Ślężę, w ramach rozruszania swoich mięśni i kości. Realizacja postanowienia wymagała przedsięwzięcia paru kroków:
Wczoraj w repozytorium pluginów symfony pojawiła się wersja 1.1.0 pluginu vjCommentPlugin, w której maczałem swoje palce. Dodałem możliwość przypięcia wysyłanych komentarzy do użytkownika, dzięki czemu można je powiązać z konkretnym użytkownikiem i wyświetlić na przykład listę jego wypowiedzi, policzyć ile posiada on komentarzy, ile tych moderowanych/usuniętych.
Wczoraj wyszła czwarta wersja symfony z linii 1.3.x i 1.4.x (Zaanonsowane na blogu symfony). Co ciekawe, poprawki wprowadzone w tej wersji częściowo adresują problem poruszony w moim poprzednim poście, dlatego postanowiłem przetestować migracje tak szybko jak na to zadania pozwolą.