Jak powinno się tworzyć triggery przy korzystaniu z EF Core? Zainstalować bibliotekę do tego czy napisać ręcznie skrypt SQL? I w ogóle jak to wygląda przy wystawianiu aplikacji na produkcję: odpala się po prostu migrację? Za pomocą EF nie da się wygenerować dokładnie takiego schematu, jakiego potrzeba (np. przez brak możliwości dodawania triggerów), więc pewnie trzeba też wykonać dodatkowy skrypt SQL. Czy ten SQL zawiera tylko część definicji bazy czy całość (migracje nie są potrzebne)?
- Rejestracja:ponad 7 lat
- Ostatnio:4 miesiące
- Postów:1065
2
A nie da się w Core dodać migracji tworzącej trigger komendą w SQL? W normalnym EF możesz wykonać w migracji dowolna polecenie SQL.
Edit
migrationBuilder.Sql(
@"
Create rrigger...
");
edytowany 1x, ostatnio: jacek.placek
- Rejestracja:około 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
0
Można ;) Zapomniałem o tym. Ale czy wszystkie problemy się w ten sposób rozwiązuje? To znaczy, czy na produkcyjnej bazie danych będę mógł po prostu odpalić migrację, czy może lepiej jakiś skrypt SQL napisany ręcznie?
- Rejestracja:około 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
0
@somekind: A jak robi się to A.D. 2019? Chcę mieć w tabeli kolumny CreatedAt i LastUpdatedAt. Jeśli chodzi o pierwszą, to faktycznie nie trzeba triggerów, bo wystarczy ustawić default constraint, ale co z drugą? [LastUpdatedAt] as current_timestamp persisted nie działa. :/
edytowany 1x, ostatnio: nobody01
Zobacz pozostałe 2 komentarze
Ale ma pewnie jakieś mechanizmy, które powoduję, że triggery są niepotrzebne.
Hmm, faktycznie, na szybko znalazłem coś takiego: https://ayende.com/blog/3987/nhibernate-ipreupdateeventlistener-ipreinserteventlistener
Triggery generalnie są niepotrzebne, z ORMem czy bez.
@somekind: W jaki sposób rozwiązałbyś problem z tego posta?
W NHibernate implementując
IPreUpdateEventListener i IPreInsertEventListener, w EF w evencie SavingChanges. Do tego potrzebny jakiś atrybut/interfejs/klasa bazowa dla modeli, aby było wiadome, które mają być audytowane.
- Rejestracja:ponad 7 lat
- Ostatnio:4 miesiące
- Postów:1065
- Rejestracja:około 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
0
@jacek.placek: A, więc to o to chodzi. ;) A już myślałem, że o to: https://docs.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-2017
- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
1
nobody01 napisał(a):
@somekind: A jak robi się to A.D. 2019? Chcę mieć w tabeli kolumny
CreatedAtiLastUpdatedAt. Jeśli chodzi o pierwszą, to faktycznie nie trzeba triggerów, bo wystarczy ustawić default constraint, ale co z drugą?[LastUpdatedAt] as current_timestamp persistednie działa. :/
To wszystko jest zadaniem dla aplikacji.
No chyba, że istnieją inne systemy piszące do tych samych tabel, wtedy faktycznie audyt na triggerach może mieć sens. (Tyle, że istnienie wielu systemów piszących do jednej tabeli też rzadko ma sens.)
nobody01 napisał(a):
@jacek.placek: A, więc to o to chodzi. ;) A już myślałem, że o to: https://docs.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-2017
SQL Server Audit wymaga chyba wersji Enterprise, więc to nie jest uniwersalne rozwiązanie. Jest to potężny mechanizm, ale też łatwo sobie nim zrobić krzywdę... miejsce na dysku potrafi się naprawdę szybko kończyć.
- Rejestracja:prawie 18 lat
- Ostatnio:14 dni
1
Temporal tables powinno wystarczyć: https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-2017