🚀 go-pugleaf

On 2019-04-23, ww <ww@o2.pl> wrote:

[...]

>> Myślę, że żaden ORM nie obsłuży triggerów.
>
> A w jaki sposób ORM miałby te triggery obsłużyć?

No obsługuje alternatywę, poprzez swoje zdarzenia.

Nie wiem w jaki sposób miałby to umożliwiać natywnie (czego chyba wymaga Marek S), 
biorąc pod uwagę niesamowity wręcz burdel i brak spójności w triggerach, pomiędzy 
różnymi typami baz.

> Bo ja ich używam do wielu rzeczy o których ORM kompletnie nie musi 
> wiedzieć.

To jest tak zwana zła praktyka. Potem inny programista siada i "rzeczy dzieją
się magicznie". Zresztą jest to jeden z głównych powodów by nie używać triggerów
(obok tego że to bazy danych są zazwyczaj najmniej skalowalnym i najwęższym
gardłem systemu i nie należy go nadmiernie obciążać).

W świecie w którym możesz mieć "na zawołanie" 1000 funkcji / kontenerów robiących coś 
równolegle na infrastrukturze cloud, odpalanych w sekundy, ale np. tylko 1-2 serwery baz 
danych, to jest oczywiste że dużo bardziej skalowalne są te ostatnie i należy je odciążyć
maksymalnie, a nie "dokładać" im niepotrzebnej tam roboty.

> I doctrine wspiera tworzenie różnych "nieporzenoszalnych"
> elementów składni SQL pod dany silnik.

Nie tyle "wspiera" co "umożliwia".

Ale koncept za jego rozwojem jednak jest taki, żeby nie dodawać rzeczy
niekompatybilnych będących specyficznymi wyłącznie dla jednego 
z obsługiwanych dialektów, chyba że nie ma innego wyjścia (jak mamy
np. w obsłudze primary keys i generation strategy.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com