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

porzuc schema:update i przerzuc sie na migracje

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?

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

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)

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

ok dzięki wielkie!

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ą.

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

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.

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?

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.

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

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.

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ę.

No dokladnie. Wiec jakby nie patrzec problemu nie ma A juz sie balem ze przeoczylem cos powaznego

Temat o którym wspomniałem:

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