That was tricky. I hope it will help somebody.

<?php
class SomeForm extends sfForm
{
	//..
 
	/**
	 * Return array of current errors
	 *
	 * @return array
	 */
	public function getErrorsArray()
	{
		$errors = $embedded_forms_name = array();
		foreach($this->getEmbeddedForms() as $embedded_form){
			$embedded_forms_name[] = $embedded_form->getName();
		}
		foreach($this as $field){
			if($field->hasError())
			{
				if(in_array($field->getName(), $embedded_forms_name)){
					foreach($field as $field_embedded){
						if($field_embedded->hasError()) $errors[$field->getName().'_'.$field_embedded->getName()] = $field_embedded->getError()->__toString();
					}
				} else {
					$errors[$field->getName()] = $field->getError()->__toString();
				}
			}
		}
		return $errors;
	}
}

For embedded forms it return embedded form name plus field name as a key. You got an idea ;-) It should be standard feature IMHO.

Update: Of course there is a easier way if you don’t have embedded forms:

//...
foreach ($this as $field) {
	$field->hasError() ? $errors[$field->getName()] = $field->getError()__toString() : null;
}

or

//...
foreach ($this->getErrorSchema()->getErrors() as $name => $error) {
	$errors[$name] = $error->getMessageFormat();
}

Usuwając coś permanentnie z bazy danych musimy być bardzo ostrożni, bowiem przywrócenie danych jest bardzo trudne, czasem niemożliwe. Podstawową strukturę bazy danych powinno się budować na samym początku tworzenia aplikacji, z biegiem czasu rozbudowywać ją, ale unikać przebudowywania. Niestety są przypadki, gdzie trzeba przebudować jedną rzecz, co powoduje zmianę w wielu warstwach nie tyle aplikacji, co strukturze bazodanowej.

Dziś postaram się opisać, jakie kroki trzeba wykonać, aby bezpiecznie usunąć zdublowane rekordy z bazy danych nie tracąc żadnych danych:

1. Tworzymy dwie kopie bazy danych lub tabel, na których będziemy pracowali. Najlepiej, aby pracować na drugiej kopii, nigdy na oryginale, a potem wdrożyć zmiany z drugiej kopii na oryginał. Przezorny zawsze ubezpieczony.
2. Analiza danych w tabeli. Musimy dokładnie wiedzieć jakie są relacje między tabelami, kiedy występują JOIN’y itp. Jeżeli rekordy są zdublowane, a posiadają ustalony ID, do których odwołuje się inny rekord z sąsiedniej tabeli, trzeba będzie w niej zmienić ID rekord zdublowanego na ID “substytuta”, bądź takiego rekordu, który nie spowoduje zmian w serwisie.
3. Wykonanie operacji usunięcia zdublowanych rekordów.

Po wykonaniu kroku pierwszego zabieramy się za kolejny. Jest to najważniejszy moment naszych operacji. Aby ułatwić zrozumienie problemu, podam przykład z życia. Aplikacja posiadała poważny błąd, który umożliwiał zdublowanie użytkowników, ściślej: można było zdublować username. Za każdym razem, gdy użytkownik się logował i pisał komentarze, był ich właścicielem, ale comment_author posiadały różne ID tego samego użytkownika. Zaraz po skopiowaniu bazy danych spróbowałem przepisać ID autorów komentarzy na pierwszy rekord identyfikujący użytkownika, jaki istnieje w tabeli użytkowników. Skonstruowałem zapytanie:

UPDATE cms_comments JOIN cms_members AS user_original ON(user_original.user_id = comment_author) SET comment_author = (SELECT user_first.user_id FROM cms_members AS user_first WHERE user_first.user_name = user_original.user_name ORDER BY user_first.user_id ASC LIMIT 0, 1)

Usunięcie zdublowanych użytkowników było już tylko formalnością. Teraz się okaże, dlaczego zależało mi na wyciągnięciu dokładnie pierwszego rekordu reprezentującego “unikalnego” użytkownika: poniższe zapytanie (ALTER IGNORE TABLE ADD UNIQUE) usunie wszystkie kolejne rekordy oznaczone jako duplicated:

ALTER IGNORE TABLE cms_members ADD UNIQUE INDEX(user_name);

Krótki komentarz z manuala do ALTER TABLE:

IGNORE is a MySQL extension to standard SQL. It controls how ALTER TABLE works if there are duplicates on unique keys in the new table or if warnings occur when strict mode is enabled. If IGNORE is not specified, the copy is aborted and rolled back if duplicate-key errors occur. If IGNORE is specified, only the first row is used of rows with duplicates on a unique key, The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value.

Pisząc ostatnie posty związane z bazami danych, mam nadzieję, że komuś się przydadzą.

Im więcej nietypowych rzeczy programuję, tym więcej nietypowych problemów musze pokonać. Co powiecie na sumę 2 liczb, z których jedna jest wartością NULL powstałą w wyniku działania SUM() lub pochodnych, gdzie nie odnaleziono żadnego rekordu.

Badamy:

SELECT 1+2+3 >> 6

SELECT 1+2+NULL >> NULL

SELECT COALESCE( NULL, 0 ) >> 0

Zatem analogicznie do powyższego przykładu:

UPDATE users SET user_points = user_points + COALESCE((SELECT SUM( ... ) WHERE ...), 0)

Punkty użytkownika już zawsze będą się sumowały poprawnie :-)

Wczorajszy dzień był “wysypem nowego oprogramowania” - nowego w sensie nowych wersji, np takich jak Firefox 3.5, PHP 5.3. Pisałem wczoraj o pgAdminie3 o wersji 1.10.0 a dzisiaj będzie o samej bazie danych PostgreSQL w wersji oznaczonej numerem 8.4.

W wersji PostgreSQL 8.4 zostały wprowadzone:

• Równoległe przywracanie bazy, które wpływa na szybkość przywracania danych
• Uprawnienia na kolumny
• pg_migrator
• Narzędzia diagnostyczne i administracyjne
• Ulepszenia zwiazanych z PLSQL i SQL
• Poprawki zwiazane z bezpieczeństwem bazy

Pełna lista zmian: http://www.postgresql.org/about/press/features84.html

Powiązane

• Symfony, Propel, PostgreSQL - Multi database (obsługa wielu baz danych w aplikacji) (3)
• Symfony - Propel Lazy Load (0)
• Pierwszy post (1)
• Klucze i indeksy w bazie danych (2)
• Cache danych w PHP - testy wydajności (MEMORY, MyISAM, Plik) (0)
• PDO prepared statements a wydajność zapytań SQL (0)

Została wydana stabilna oznaczona numerem v1.10.0 wersja pgAdmina. Pojawiły sie nowe bajery jak np. “graphical query builder” i lepsza obsługa PostgreSQL 8.4.

Kilka screenów prezentujących nowe funkcjonalności nowego PgAdmina.

Graphical query builder - budowanie zapytań za pomocą myszy.

pgScript scripting framework.

Wsparcie dla obiektów FTS.

Tryb edycji i wykonania SQL z poziomu edycji tabeli.

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

Zwiń
Czytaj na blogu autora...

Dzisiaj światło dzienne ujrzała kolejna odsłona jednego z najpopularniejszych języków skryptowych – PHP oznaczone wersją 5.3. Wersja ta jest znacząca w rozwoju PHP, będąca swego rodzaju pośrednikiem pomiędzy wersją 5 a 6. Główne funkcjonalności wprowadzone w PHP 5.3 to: - przestrzenie nazw (ang. namespaces), pozwalające na jeszcze lepszą enkapsulację elementów, więcej: http://pl.php.net/manual/en/language.namespaces.php - funkcje anonimowe [...]

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.