Problem utrzymywania aktualnej wersji jest już szeroko znany przy utrzymywaniu kodu. Powstało więc wiele systemów kontroli wersji (CVS,SVN,Git,Mercurial ...).

Struktura bazy danych to jednak nie do końca to samo. W bazie danych nie mamy kodu który w danej wersji jest zawsze taki sam. Jest coś więcej. Są dane. Problem polega więc nad tym, aby przy aktualizacji schematu bazy danych do najnowszej wersji nie "zepsuć" bazy. Na czym więc nam dodatkowo zależy :

• Aby schemat otrzymał nowe elementy(pola, tabele, klucze, triggery) z aktualnej wersji
• Aby nie utracić danych
• Aby dane nadal były spójne

Dodatkowo, na samym środowisku docelowym wykonywane są czasami jakieś dodatkowe zmiany. Dodawane są klucze, czasami jakieś małe zmiany w polach. Zależy nam więc jak zwykle na zmniejszeniu liczby zależności przy wprowadzaniu zmian Zależy nam też na uodpornieniu procesu aktualizacji na błędy związane z rozbieżnościami oczekiwanego i otrzymanego na początku schematu.

Podejście chałupnicze

Przy małej ilości zmian lub rzadkich wdrożeniach na wersję produkcyjną możemy to załatwić ręcznie.

• Możemy to zrobić porównując ręcznie schemat z bazy z tym z pliku schematu
• Możemy przy zmianach tworzyć proste pliki tworzące wykonujące zmiany i podsyłać wraz z kodem
• Możemy zrzuć dane do pliku, wyczyścić bazę, wrzucić nowy schemat i dane z pliku

Wszystkie metody powyższe dają efekty. Są jednak wrażliwe na błędy, i często wymagają odłączenia aplikacji od bazy.

Opis narzędzia

Narzędzie, którego od nie dawna używam, to DbDeploy. Pozwala ono na zarządzanie schematem bazy danych w oparciu o zbiór skryptów zmieniających ją. Narzędzie napisane jest w Javie, można podpiąć je do narzędzia ANT.

Skrypty te numerowane są na podstawie ich nazwy. 3 pierwsze znaki oznaczają numer, a zarazem kolejność wprowadzania ich do bazy. Są to w zasadzie zwykłe skrypty SQL, jednak przy pomocy odpowiednich komentarzy mamy możliwość tworzenia skryptów cofania zmian.

Narzędzia można używać jako target do narzędzia ant, jak i jako narzędzie command line

Workflow

Przy DbDeploy przyjmuję następujący tryb pracy :

• Wykonanie poprawki do bazy w języku SQL (nie koniecznie ręcznie, z pomocą mogą przyjść mysql-workbench lub inne narzędzia okienkowe)
• Zapisanie jej w katalogu ze skryptami używanego przez DbDeploy
• Nałożenie poprawki na bazę danych przy pomocy DbDeploy

Należy tutaj podać następujące założenia :

• Po umieszczeniu pliku poprawki i nałożeniu jej nie powinno się jej zmieniać lub usuwać
• Kolejne zmiany to koniecznie kolejne pliki z poprawkami

Cały katalog wraz z zbiorem skryptów, samym DbDepoy, sterownikiem bazy danych i konfiguracją (build.xml) trzymam pod kontrolą bazy danych. Pozwala to na jednoczesne aktualizowanie kodu i schematu na serwerach docelowych. Przy aktualizacji tych repozytoriów natychmiast można zauważyć pojawiające się pliki z poprawkami do bazy danych. Uruchomienie ant w odpowiednim katalogu, i baza jest już aktualna.

Przykładowa zmiana

Załóżmy, że w bazie danych przechowujemy tabelę z użytkownikami, której struktura zapisana jest w pliku 001-base.sql

CREATE  TABLE IF NOT EXISTS User (
	idUser INT NOT NULL AUTO_INCREMENT ,
	email TINYTEXT NOT NULL ,
	pasword CHAR(40) NOT NULL ,
	salt CHAR(23) NOT NULL ,
	meta TEXT NOT NULL ,
	created DATETIME NOT NULL ,
	lastLogin DATETIME NOT NULL ,
	PRIMARY KEY (idUser) )
	ENGINE = InnoDB|

Aby rozpocząć pracę, uaktualniamy plik build.xml o dane do bazy danych, wykonujemy ant clean w celu utworzenia tabeli do przechowywania stanu schematu.

ert16@mert dbdeploy> ant clean
Buildfile: /home/ert16/dbdeploy/build.xml

create-changelog-table:
		[sql] Executing resource:
 /home/ert16/dbdeploy/lib/createSchemaVersionTable.mysql.sql
		[sql] 2 of 2 SQL statements executed successfully

clean:

BUILD SUCCESSFUL
Total time: 5 seconds

Następnie ustawiamy aktualną wersję bazy danych.

ert16@mert dbdeploy> ant Buildfile: /home/ert16/dbdeploy/build.xml

update-database:
 [dbdeploy] dbdeploy 3.0M3
 [dbdeploy] Reading change scripts from directory /home/ert16/dbdeploy...
 [dbdeploy] Changes currently applied to database:
 [dbdeploy]   (none)
 [dbdeploy] Scripts available:
 [dbdeploy]   1
 [dbdeploy] To be applied:
 [dbdeploy]   1
 [dbdeploy] Applying #1: 001-base.sql...
 [dbdeploy]  -> statement 1 of 11...
 [dbdeploy]  -> statement 2 of 11...
 [dbdeploy]  -> statement 3 of 11...
 [dbdeploy]  -> statement 4 of 11...
 [dbdeploy]  -> statement 5 of 11...
 [dbdeploy]  -> statement 6 of 11...
 [dbdeploy]  -> statement 7 of 11...
 [dbdeploy]  -> statement 8 of 11...
 [dbdeploy]  -> statement 9 of 11...
 [dbdeploy]  -> statement 10 of 11...
 [dbdeploy]  -> statement 11 of 11...

default:

BUILD SUCCESSFUL
Total time: 3 seconds

Chciałbym do tabeli dołożyć pole emailHash, które będzie skrótem sha1 pola email. Realizacja skrótu będzie wykonywana na poziomie aplikacji piszącej do bazy danych. Tworzę więc następującą poprawkę :

ALTER TABLE User 
	ADD COLUMN emailHash CHAR(32)
		CHARACTER SET 'ascii'
		COLLATE 'ascii_general_ci'
		NOT  NULL AFTER lastLogin ,
	ADD UNIQUE INDEX emailHash_UNIQUE (emailHash ASC) |

UPDATE User 
	SET emailHash=md5(email)|

Umieszczam ją w katalogu dbDeploy pod nazwą 002-emailHashField.sql i wykonuję ant

ert16@mert dbdeploy> ant
Buildfile: /home/ert16/dbdeploy/build.xml

update-database:
 [dbdeploy] dbdeploy 3.0M3
 [dbdeploy] Reading change scripts from directory /home/ert16/dbdeploy...
 [dbdeploy] Changes currently applied to database:
 [dbdeploy]   1
 [dbdeploy] Scripts available:
 [dbdeploy]   1, 3
 [dbdeploy] To be applied:
 [dbdeploy]   3
 [dbdeploy] Applying #3: 002-emailHashField.sql...

default:

BUILD SUCCESSFUL
Total time: 3 seconds

Po pewnym czasie, przypominam sobie jednak, że md5 jest już przestarzałe, i warto by było, aby zmienić tą sumę na sha1. Co więc należy zrobić ? Oczywiście, kolejna poprawka.

ALTER TABLE User 
	CHANGE COLUMN emailHash emailHash CHAR(40)
		CHARACTER SET 'ascii'
		COLLATE 'ascii_general_ci'
		NOT  NULL |
UPDATE User SET emailHash=sha1(email)|

Po zapisaniu jako 003-emailhashField-fix.sql i wykonaniu ant baza schemat jest już aktualny.

ert16@mert dbdeploy> ant
Buildfile: /home/ert16/dbdeploy/build.xml

update-database:
 [dbdeploy] dbdeploy 3.0M3
 [dbdeploy] Reading change scripts from directory /home/ert16/dbdeploy...
 [dbdeploy] Changes currently applied to database:
 [dbdeploy]   1, 3
 [dbdeploy] Scripts available:
 [dbdeploy]   1, 3, 4
 [dbdeploy] To be applied:
 [dbdeploy]   4
 [dbdeploy] Applying #4: 003-emailhashField-fix.sql...
 [dbdeploy]  -> statement 1 of 2...
 [dbdeploy]  -> statement 2 of 2...

default:

BUILD SUCCESSFUL
Total time: 4 seconds

Napotkane problemy

Dokumentacji do tego narzędzia nie oceniam dobrze. Czasami jest mi ciężko się w niej odnaleźć.

Konfiguracja DbDeploy jest dość problematyczna. Dołączony skrypt build.xml był dla mnie mało przeźroczysty, co zmusiło mnie do jego przebudowania. Chodziło mi głównie o wyciągnięcie parametrów dostępu do bazy danych na początek pliku i usunięcie niepotrzebnych celów. Do działania wymagana jest również konfiguracja sterownika do bazy danych. Trzeba umieścić ją w odpowiednim miejscu i zmienić konfigurację.

Miałem również pewne problemy przy umieszczaniu w bazie triggerów. Zmusiło mnie to do zmiany parametru delimiter co widać w powyższych skryptach.

Przydatne materiały

• Mój działający dla MySQL setup DbDeploy http://svn.trojniak.net/czytnikrss/trunk/docs/dbdeploy/
• Inne prezentacje http://www.slideshare.net/harrieverveer/database-version-control-without-pain-the-dpc-version
• Strona projektu http://dbdeploy.com/

Na początek same formularze. Dla przykładowego projektu typu CRUD(Create, Read, Update, Delete) zazwyczaj wystarczą 3 formularze : Dodania, Edycji i potwierdzenia usunięcia. Ja Zazwyczaj tworzę więc 3 formularze :

zf create form AreYouSure
zf create form PageCreate
zf create form PageEdit

Zend_Tool wygenerował nam 3 szkielety formularzy:

class Application_Form_AreYouSure extends Zend_Form
{
    public function init()
    {
        /* Form Elements & Other Definitions Here ... */
    }
}

class Application_Form_PageCreate extends Zend_Form
{
    public function init()
    {
        /* Form Elements & Other Definitions Here ... */
    }
}

class Application_Form_PageEdit extends Zend_Form
{
    public function init()
    {
        /* Form Elements & Other Definitions Here ... */
    }
}

Pola w formularzach

Typy pól w formularza zazwyczaj odzwierciedlają bazę danych. To jak przechowujemy dane odzwierciedlone powinno być w sposobie ich wprowadzania. Możemy więc zdefiniować przykładowe pola :

• Title - tytuł wpisu
• Head - nagłówek wpisu
• Body - Treść wpisu
• Type - typ wpisu
• Email - Adres autora

Ponieważ pola wykorzystywane są w obydwóch z formularzy (Create i Edit) umieszczamy je w osobnych klasach. Ja zazwyczaj w tym celu tworzę dodatkowy katalog form/Element . Umieszczam w nich klasy dla każdego z pól.

Klasy te dziedziczę po klasach z biblioteki. Przykładowymi klasami przydatnymi do dziedziczenia są Text, Textarea, Select oznaczających typowe elementy formularzy znane z HTMLa.

class Application_Form_Element_Body extends Zend_Form_Element_Textarea
{
    public function init()
    {
    }
}

class Application_Form_Element_Email extends Zend_Form_Element_Text
{
    public function init()
    {
    }
}

class Application_Form_Element_Head extends Zend_Form_Element_Textarea
{
    public function init()
    {
    }
}

class Application_Form_Element_Title extends Zend_Form_Element_Text
{
    public function init()
    {
    }
}

class Application_Form_Element_Type extends Zend_Form_Element_Select
{
    public function init()
    {
    }
}

Jak już mamy elementy formularzy, umieszczamy je na swoim miejscu. Każde z pól dodajemy do formularza w funkcji init. Do konstruktora obiektu pola przekazujemy jego indeks w formularzu. To po tym indeksie będziemy pobierać wartość danego pola z formularza.

class Application_Form_AreYouSure extends Zend_Form
{

	public function init()
	{
		$this->addElement(new Zend_Form_Element_Submit('yes'));
		$this->addElement(new Zend_Form_Element_Submit('no'));
	}

}

class Application_Form_PageCreate extends Zend_Form
{

	public function init()
	{
		$this->addElement(new Application_Form_Element_Title ('title'));
		$this->addElement(new Application_Form_Element_Head ('head'));
		$this->addElement(new Application_Form_Element_Body ('body'));
		$this->addElement(new Application_Form_Element_Type ('type'));
		$this->addElement(new Application_Form_Element_Email ('email'));
		$this->addElement(new Zend_Form_Element_Submit('create'));
	}

}

class Application_Form_PageEdit extends Zend_Form
{

	public function init()
	{
		$this->addElement(new Application_Form_Element_Title ('title'));
		$this->addElement(new Application_Form_Element_Head ('head'));
		$this->addElement(new Application_Form_Element_Body ('body'));
		$this->addElement(new Application_Form_Element_Type ('type'));
		$this->addElement(new Application_Form_Element_Email ('email'));
		$this->addElement(new Zend_Form_Element_Submit('save'));
	}
}

Dekoratory

Kolejnym krokiem jest praca nad samą prezentacją formularza użytkownikowi. W tym celu używam domyślny zestaw dekoratorów odpowiadających za wygenerowanie HTML. Przydatnych jest przy tym kilka funkcji, które pozwalają na ustawienie etykiety pola (setLabel ) i opisu ( setDescription) . Przykładowo klasa elementu Head będzie teraz wyglądał następująco :

class Application_Form_Element_Head extends Zend_Form_Element_Textarea
{
    public function init()
    {
			$this
				->setLabel('Nagłówek')
				->setDescription('Ta część artykułu pojawiać się będzie na stronie głównej, oraz w widoku detalu artykułu')
				;
    }
}

Filtry i Validatory

Po odebraniu danych możemy przepuścić je przez różne filtry. Przydaje się tutaj głównie Zend_Filter_StringTrim. Dzięki niemu w kluczowych polach nie pojawiają się zbędne spacje na początku i końcu.

Sprawdzanie poprawności wprowadzonych danych jest bardzo ważną rzeczą. Pozwala to na zabezpieczenie się przed atakami i upewnienie, że użytkownik wpisał to, co powinien. Zend daje nam do tego szeroką gamę validatorów, które musimy tylko przypiąć i ustawić zgodnie z nasza bazą danych. Często zapomnianą rzeczą do sprawdzenia jest długość pól. Ponieważ w bazie danych większość pól ma swoje ograniczenia warto zablokować ich przekraczanie.

Uzupełniona klasa elementu Title będzie wyglądała tak :

class Application_Form_Element_Title extends Zend_Form_Element_Text
{
    public function init()
    {
			$this
				->setLabel('Tytuł')
				->addFilter('StringTrim')
				->addValidator('StringLength', false, array('max'=>255) )
				;
    }
}

Użycie

Tak stworzone formularze bardzo pomagają w pracy z danymi otrzymywanymi od użytkownika. Głównymi funkcjami przydatnymi do użytku są :

• isValid($data) - ustawia wartości pól i sprawdza, czy dane spełniają warunki walidatorów.
• getValues() - pobiera wartość wszystkich pól po przefiltrowaniu w postaci tablicy
• getValue($name) - pobiera wartość z pola o danym indeksie
• setValues($arr) - ustawia wartości pól na podstawie tablicy
• setValue($index,$arr) - ustawia wartości pola
• __toString() - Pozwala na wyświetlenie formularze przez użycie echo $formularz

Podsumowanie

Formularze w Zend pozwalają na pobranie, przetworzenie, sprawdzenie danych oraz wyświetlenie wypełnionego formularza. Praca z formularzami jest prosta, oraz wydajna. Kod formularza może być wykorzystywany wielokrotnie na wielu poziomach, dzięki wydzieleniu klas jego elementów do osobnych obiektów.

Wsparcie dla komentarzy (żebyście mogli się na artykułach wyżywać) w planie. Do tego czasu zapraszam do pisania do mnie.

Skrypt wymaga również innego dopracowania, głównie stylizacji i małych poprawek. Myślę jednak, że nadszedł już czas aby umieścić go pod tym adresem.

A o czym dokładnie chciałbym pisać ?

Narzędzia

Bo narzędzia są tym, co pozwala nam się rozwijać. Bez narzędzi nadal jedlibyśmy owoce, a spalibyśmy w jaskiniach. Przez poznawanie nowych narzędzi możemy pracować szybciej, i tworzyć lepsze produkty.

Ja skupiać się będę głównie na narzędziach wykorzystywanych w administracji , tworzeniu stron internetowych przy użyciu języka PHP , ogólnej pracy z systemami z rodziny Linux. Zapraszam do obserwowania tagów które dotyczą tych działek.

Ciekawe rozwiązania

W świecie oprogramowania wiele rzeczy można wykonać na wiele sposobów. Jedną operację można wykonać na wiele sposobów. Niektóre są lepsze w jednych sytuacja, inne w innych.

Wykonywane projekty

A może któryś z wykonywanych projektów Ci się przyda ? Może Cię do czegoś zainspiruje ?