🚀 go-pugleaf

W dniu 2019-04-21 o 14:25, Wojciech Bancer pisze:

>> Bardzo niewygodnie tworzy się struktury bazodanowe używając make:entity
>> i potem zastanawiając się czy np. pole "string" stanie się varchar czy
>> text itd.
> 
> To może warto przeczytać instrukcję, skoro to dla Ciebie aż takie istotne?
> Już nawet nie cały, ale podstawy by wypadało.

Faktem jest, że gdy już wszystko zawiedzie, należy przeczytać instrukcję :-D

> Myślę, że żaden ORM nie obsłuży triggerów. A do tego mają swoje constraints,
> których nie uświadczysz na surowej bazie (jak np. obsługa tablic wartości, czyli
> np. typ simple_array albo array).

A teraz na poważnie: napisałeś wcześniej, że należałoby przeczytać 
instrukcję, a teraz piszesz, że i tak by mi to nic nie dało gdyż 
funkcjonalność, o którą pytam nie jest wspierana przez ORMy.

Cenię Twoją wiedzę, ale nauczyciel z Ciebie kiepski ;-) Ale cóż, 
przecierpię :-D

> Triggery nie są one uniwersalne, więc żaden ORM nie będzie ich raczej obsługiwać.

Jak zatem w praktyce takie rzeczy się robi? Oczywiście mógłbym ręcznie 
dopisywać coś do migracji lecz jest w tym pewnego rodzaju zagrożenie: 
otóż w fazie DEV, szczególnie gdy stawia się pierwsze kroki w tematyce, 
łatwo o błędy. Zdarzało mi się automatycznie tworzyć migracje, usuwać je 
po wycofaniu, poprawić coś tam i jeszcze raz generować. Gdybym ręcznie w 
nich grzebał, to utraciłbym dodatkowe zmiany.

Jak zatem od strony praktycznej dołączasz nie-ORMowe wstawki? Tworzysz 
oddzielne, ręczne migracje?

>> Czy jest jakaś możliwość aby ORM zbudował się na podstawie albo pliku
>> SQL, albo na postawie tego, co jest w bazie?
> 
> A zadałeś te pytanie w google, zanim napisałeś na grupę?
> Bo na hasło "doctrine import db" masz odpowiedź w 1 linku.

Mądralo, gdybym wiedział o co pytać by w poprawnym kierunku podążać, to 
nie zadawałbym tu pytań.

Odpowiadając: owszem, szukałem w Google... ale narzędzi do tego (czyli 
export to doctrine, convert to doctrine). I tak np. analizowałem Navicat 
pod kątem tego, czy potrafi wygenerować coś dla ORMów. Nie pomyślałem, 
że sam ORM takie rzeczy potrafi sam z siebie robić, ma wbudowane 
importowanie. A dlaczego nie pomyślałem? Wyjaśniam poniżej.

Lokalnie też podpytywałem kolegów, którzy mieli z jakimikolwiek 
frameworkami do czynienia. Wszyscy niestety, jak rzemieślnicy przy 
taśmie fabrycznej, tworzyli encje poprzez frameworki, nigdy odwrotnie. 
Jeden z nich nawet sądzi, że klucze obce tworzy się za pomocą Join'ów. 
Stąd podświadomie założyłem, że ORM to jednokierunkowy mechanizm w 
zakresie tworzenia struktur w bazach.

Uwaga do Ciebie: bierz pod uwagę, że osoby wdrażające się w jakikolwiek 
temat potrafią błądzić i rozpatrywać nawet absurdalne sposoby realizacji 
jakiegoś zadania. A już w szczególności, gdy lokalne środowisko 
zaciemnia właściwe podejście. Także trochę przyhamuj z łaski swojej z 
takimi pytaniami.

-- 
Pozdrawiam,
Marek