Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [SF][SF2] Entity - aktualizacja struktury tabeli
Forum PHP.pl > Forum > PHP > Frameworki
wujek2009
Cześć.

Utworzyłem nową tabelę w bazie i teraz chciałbym utworzyć dla niej klasę w Entity. Samą klasę utworzyłem (+ repozytorium), ale domyślnie w klasie User (oraz User.orm.yml) jest tylko jedną kolumna "id" - która została utworzona automatycznie przez Symfony2.

Ogólnie w bazie mam już tabelę, która jest uzupełniona o wszystkie potrzebne mi pola - tylko nie wiem w jaki sposób uaktualnić schematy, tak aby źródłem była tabela "users" w bazie - W tej chwili porównuje w dość dziwny sposób: PLIKI => TABELA - wolałbym, aby symfony2 wygenerował schemat według struktury, którą ułożyłem w tabeli "users" a nie w plikach YML

Polecenie:
Kod
php app/console doctrine:schema:update --dump-sql

zwraca mi:

1) wyrzucenie wszelkich indeksów co nałożyłem na tabele "users"
2) wyrzucenie wszystkich kolumn, które utworzyłem (prócz "id")

Jest jakiś sposób, aby pobierało schemat z tabeli a nie z plików YML? Wygodniej jest mi tworzyć najpierw tabelę niż wprowadzać pola tabeli w konsoli.
pyro
Sam zamysł Doctrine ORM to praca na obiektach tak jak całe DQL, nie powinieneś nic robić po stronie bazy danych. Biblioteki Doctrine zajmują się tym za Ciebie.

Istnieje możliwość stworzenia entities na podstawie bazy danych, ale powinno się tego używać tylko w niektórych, szczególnych przypadkach. Ty osobiście nie chcesz pracować na bazie danych, tylko na obiektach.

Dodatkowa lektura:
http://symfony.com/doc/current/cookbook/do...ngineering.html
wujek2009
Dzięki za wyjaśnienie, będę trzymał się raczej standardów i budował bazę za pomocą biblioteki Doctrine. Zastanawiam się nad dostępnością pola typu "text" - cały czas konwertuje mi go na "longtext" gdy wykonuje polecenie:
Kod
php app/console doctrine:schema:update --force


To normalne?
pyro
Tak
wujek2009
Nieciekawe. Podobna sytuacja jest z typami liczb: tinyint, mediumint - godzicie się z tym, czy jednak modyfikujecie kod SF2, aby akceptował te dane? Nie chce wpadać w paranoje, ale dla danej kolumny wolałbym tinyint (tj: zakres liczb do 255) zamiast już smallint (65535).
pyro
A w czym to robi różnicę z punktu widzenia skryptu?
wujek2009
Z punktu widzenia skryptu pewnie nic, ale co z wagą bazy? Czy źle dobrany typ kolumny może niepotrzebnie zapychać miejsce w bazie? Prawdopodobnie są to małe różnice, ale kiedyś kładło się na to nacisk. Oczywiście luźnie tak kontynuuje wątek, nie che wpadać w skrajność - bardziej interesuje mnie zdanie innych programistów.
pyro
Spadek wydajnościowy w takim wypadku wynosi jakieś... ~0%
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.