[Symfony2][Symfony]Ręczne utworzenie encji i tabeli, jak? Opcje

[robert0770]

Witam, do tej pory korzystałem z adnotacji i funkcji doctrine:schema:update
Ale mój projekt jest dość spory i nie moge użyć schema:update dla całego projektu gdyż nie chce ingerować w resztę map(a wywala mi przy sql-dump wiele modyfikacji do innych tabel), zależy mi tylko na utworzeniu jednej encji zmapowaniu jej i stworzeniu tabeli dlatego chyba najlepszym rozwiązaniem będzie zrobienie tego ręcznie gdyż w schema:update nie mogę wskazać encji która bym chciał zmapować

napisałby mi ktoś w paru krótkich słowach jak się do tego zabrać? szczegóły sam obadam w internecie, zależy mi bardziej na jakimś schemacie działania

Ten post edytował robert0770 6.06.2017, 12:25:42

[nospor]

porzuc schema:update i przerzuc sie na migracje

[robert0770]

w sumie cos jest w consoli
doctrine:migrations:generate
Tym załatwie sprawie?
utworzy mi kod sql ktory nastepnie wklepie do bazy?
utworzy proxies encji?

i wszystko na podstawie encji z adnotacjami?

[nospor]

Moze poprostu przeczytaj dokumetnacje, a bedziesz wiedzial jak dzialaja migracje

http://symfony.com/doc/current/bundles/Doc...ndle/index.html
Migracja to poprostu kod z php z komendami sql, ktore nalezy wykonac. Czy ty ten kod wygenerujesz recznie, czy posluzysz sie narzedziem, to juz inna bajka.
Z migracjami masz kontrole nad tym co sie wykona w bazie

[robert0770]

tak wiem, dzięki za odpowiedź

swoim pytaniem bardziej miałem na myśli czy w sekcji migracji utworzy się połączenie między encja a juz faktyczną tabelą (pewnie jakięś z cachowane informacje)

[nospor]

Tam naprawde nie ma zadnych magicznych polaczen. Jesli w bazie jest wszystko to, na co wskazuje encja, to wszystko bedzie dzialac, niezaleznie czy to bylo tworzone przez schema:update, czy przez migracje, czy przez reczne rezanie w bazie.

W najgorszym wypadku bedziesz musial poprostu wyczyscic cache

[robert0770]

ok dzięki wielkie!

[Puszy]

Jeżeli korzystasz z PostgreSQL to pamiętaj że migracje czasami przy zrucaniu klucza w down() nie posiadają nazw schematów co może powodować rozjazdy między migracjami a bazą.

[nospor]

@Puszy mozesz rozwinac watek? Szczerze powiedziawszy nie rozumiem co teraz napisales

[Puszy]

Gdy wymagane będzie zrzucenie indeksu to zamiast

[SQL] pobierz, plaintext 
DROP INDEX foo_schema.idx_bca055d29395c3f3;
[SQL] pobierz, plaintext 

będziesz miał

[SQL] pobierz, plaintext 
DROP INDEX idx_bca055d29395c3f3;
[SQL] pobierz, plaintext 

W przypadku PG 9.4 klucz nie zostanie usunięty. Migracja się wykona ale indeks dalej będzie istniał. I w przypadku gdy zrobisz up, down, up migracja wysypie się bo będziesz chciał dodać klucz który de facto już istnieje.

Ten post edytował Puszy 12.06.2017, 15:58:00

[nospor]

No dobra, ale jesli bede chcial usunac index bez schemy, a co za tym idzie index nie bedzie istnial, to powinien dostac error przy robieniu down, nieprawdaz?

[Puszy]

No to być może od razu przy down sypnie błędem, mówię trochę z pamięci bo mam już nawyk do tych schematów. W każdym razie jest to znany problem, zgłoszony do twórców Doctrine i póki co nie zapowiada się na oficjalny fix. Ale sprawdzę bo jestem niemal pewien że to przejdzie.

Ten post edytował Puszy 12.06.2017, 16:01:48

[nospor]

Dokladnie, sypnie bledem, a co za tym idzie rollback sie nie powiedzie.
Kolejna rzecz, ze jak dzialasz na domyslnej schemie, to problemu w ogole nie bedzie.
I kolejna rzecz to migracje pisze sie zazwyczaj recznie, owszem mozna sie posilkowac doctrine, ale jak piszesz recznie to chyba wiec co piszesz (IMG:style_emoticons/default/wink.gif)

No i najwazniejsza rzecz na koniec:
jak piszesz migracje, to zawsze musisz je sprawdzic. Ja gdy walne migracje to ja odpalam, sprawdzam co jest w bazie, potem dobie down, sprawdzam co jest w bazie, potem robie znowu migracje. Nawet wiec jesli index by sie nie usunal, to przy ponownym up juz by mi to wychwycilo. Nie wyobrazam sobie robienie migracji bez sprawdzenia jej.

[Puszy]

Sprawdzenie jest wymagane jak najbardziej, chociazby gdy Twoja lokalna baza zawiera migracje np z innego brancha. Ja tworzę migrację przez diff a nastepnie ręcznie przeglądam SQLe i ewentualnie je dostosowuję.

[nospor]

No dokladnie. Wiec jakby nie patrzec problemu nie ma (IMG:style_emoticons/default/smile.gif) A juz sie balem ze przeoczylem cos powaznego

[Puszy]

Temat o którym wspomniałem:

https://github.com/doctrine/dbal/issues/2535