[EF][Code First] Möglichkeit zum Einfügen der Serverzeit?
-
Gibt es eine Möglichkeit einem Datenfeld im Entity Framework (Code First-Ansatz) ein Datenfeld zuzuweisen, das die aktuelle Serverzeit beim Schreiben annimmt?
Konkret geht es mit um den Zeitpunkt der Erstellung (Sprich einmalig beim Insert) und den Zeitpunkt der letzten Aktualisierung (Sprich bei einem Insert oder Update). Tendenziell sollte dies mit Triggern funktionieren, nur wie kann man dem Entity Framework beibringen das sich diese Spalten beim Speichern ändern können?
-
Ich denke mal, du wirst um ein Refresh nicht herumkommen. Ich weiß nicht welches DBMS du im Einsatz hast, aber wir verwenden Firebrid. Da muss man sich nicht umständlich mit SqlDependencies herum schlagen. Da gibt es eine nette Funktionalität, die sich POST_EVENT nennt. Alternativ kannst du auch deine "SaveChanges" Methode überschreiben, die die geänderten Datensatze ziehen und danach die Datensätze explizit updaten.
Vielleicht hilft dir das ja irgendwie weiter...
-
secondsun schrieb:
Ich denke mal, du wirst um ein Refresh nicht herumkommen. Ich weiß nicht welches DBMS du im Einsatz hast, aber wir verwenden Firebrid. Da muss man sich nicht umständlich mit SqlDependencies herum schlagen. Da gibt es eine nette Funktionalität, die sich POST_EVENT nennt...
Anfangs wohl MSSQL, wobei wir möglichst weitgehend DBMS-Unabhängig sein wollen, somit auch nicht auf spezielle Funktionalitäten zurückgreifen die sich nicht einigermaßen einfach auf anderen Servern umsetzen lassen (z.B. sind Trigger, wenn auch mit etwas anderer Syntax, auf eigentlich allen "richtigen" DBMS vorhanden).
Und grundsätzlich werde ich auf keine Funktionalitäten zugreifen, wo ein DBMS die Clients selbsständig über Änderungen informiert (Aus mehreren Gründen: a) weil dies sich nicht sinnvoll weitgehend DBMS-Unabhängig realisieren lässt, b) weil solche Mechanismen nicht selten auch Nachteile [Performance etc.] mit sich bringen und c) weil unsere Datenzugriffsschicht die Oberfläche nicht kennt, und nur zum Zeitpunkt einer Aktion Rückgaben an einen Client machen kann - Die DAL und Businesslogik wird komplett vom Client ausgelagert und per WCF Service angesprochen).
Daher ist für mich der einzige Eingriffspunkt mehr oder weniger der Schreibvorgang, die Frage ist, ob man auch mit Code First irgendwie sinnvoll die Rückgaben konfigurieren kann (So wie z.B. bei Code First bei neuen Datensätzen ja die Id auch vom Server wieder ausgelesen wird, dies nach Möglichkeit auch auf andere Felder anpassen zu können).
Im wesentlichen wird dies wohl mittels "DatabaseGeneratedOption.Computed" und ähnlichen möglich sein, wobei ich noch am recherchieren bin wie dies genau geht.
Nachtrag: Dies geht leider wohl nur wenn ich Code First mit einer existierenden Datenbank verwende.
-
Ich wollte keine grundsatzdiskussion lostreten sondern dir einen Lösungsansatz bieten. Nicht mehr und nicht weniger. Dass ihr unabhängig bleiben wollt, konnte ich nicht wissen.
Zudem mal doch nicht alles so schwarz;-) Wir haben eine relativ große Software Lösung die stark auf das automatische Updaten der Clients setzt. Was die Performance angeht... man muss eben wissen wie es richtig geht.
Wir arbeiten da speziell mit Triggern die das POST_EVENT auslösen und lesen alles über eine Tabelle. Sprich, sobald sich eine Tabelle geändert hat, schreibt sie ihren Namen via insert or update in eine Tabelle mit TimeStamp und diese lesen wird dann aus. Das reduziert den Traffic enorm.
-
secondsun schrieb:
Ich wollte keine grundsatzdiskussion
Ich habe mit deinen Antworten auch kein Problem, nur passen sie hier nicht, zumal POST_EVENT auch imho garnicht zu meinen initialen Anforderungen passten. Trigger etc. die bei Insert/Update auslösen sind meines Erachtens nichts für Änderungsbenachrichtigungen (Zumal man hier den Zeitpunkt direkt kennt).
Konkret geht es mir einfach darum das beim "Code First"-Ansatz beim Insert und Update unter gewissen Umständen einige Werte aus der Datenbank wieder ausgelesen werden (z.B. bei DatabaseGeneratedOption.Identity) und ob man diesen Mechanismus auch für solche Felder nutzen kann.
Wie gesagt habe ich dies nun herausgefunden, wenn auch leider mit der Einschränkung das die Datenbank dazu bereits existieren muss (Für mich angenehmer, aber vielleicht geht dies auch, wäre es wenn ich die Datenbankgenerierung so anpassen könnte, das ich hier einschreiten könnte um in diesen speziellen Fällen den Prozess (je nach ausgewähltem DBMS) anpassen könnte. Die DBMS spezifischen Dinge würde ich dann mit einem allgemeinen Interface auf verschiedene DLLs aufsplitten.
secondsun schrieb:
Dass ihr unabhängig bleiben wollt, konnte ich nicht wissen.
In unseren Fall sogar unabhängig von mehreren Faktoren: Sowohl der Form des Clients (WPF, ASP.NET, WP7... - Nach Möglichkeit mit weitreichenden "Code Sharing") als auch weitgehend von der Datenbank.
secondsun schrieb:
Sprich, sobald sich eine Tabelle geändert hat, schreibt sie ihren Namen via insert or update in eine Tabelle mit TimeStamp und diese lesen wird dann aus. Das reduziert den Traffic enorm.
Ich sehe hier keine Trafficeinsparung, wenn Code First Teile der Datensätze eh ggf. erneut einliest (z.B. eine DB-Generierte Id), und man eine fest definierten Zeitpunkt hierfür hat.