Pomelo.entityframeworkcore.mysql: Gerüst-ServerVersion()-Aufruf
Wir bauen derzeit nicht das ServerVersion Gerüst ein, das vom Datenbankserver verwendet wird.
Angesichts der unterschiedlichen Implementierungen von MySQL-kompatiblen Datenbankservern und immer noch starker Entwicklung auf der Funktionsseite von MySQL verwenden wir in vielen Teilen des Pomelo-Anbieters serverversionsspezifische Anweisungen.
Obwohl Benutzer beim Einrichten eines DbContext immer die erwartete (oder minimal unterstützte) Serverversion angeben sollten, sind sich viele Benutzer dessen nicht bewusst und verwenden daher die Standardserverversion, die die neueste ist.
Wie wir am Mittwoch besprochen haben, hilft das Gerüst der tatsächlichen ServerVersion dieses Problem zumindest in den Fällen zu vermeiden, in denen Benutzer davon ausgehen, dass der eingerüstete Code vollständig ist und nicht geändert werden muss, was später zu Fehlern führen könnte , wenn Pomelo neu eingeführte MySQL-Funktionen verwendet, die von der älteren Version der vom Benutzer verwendeten zugrunde liegenden Datenbank noch nicht unterstützt werden.
Dies ist der erste Schritt, um die Serverversion beim Einrichten eines DbContext für Pomelo explizit festzulegen.
Es sollte funktional dem ausrangierten # 932 PR entsprechen.
/cc @ajcvickers , @roji
lauxjpn
Alle 3 Kommentare
Beachten Sie, dass, wenn Sie möchten, dass Singleton-Dienste von der Version betroffen sind (zB TypeMappingSource, QuerySqlGenerator), eine Modellannotation nicht ausreicht, es sei denn, ich liege falsch - Sie benötigen etwas, das ISingletonOptions erbt. Dies führt dazu, dass ein neuer Dienstanbieter für andere erstellt wird und eine andere Instanz jedes Singleton-Dienstes instanziiert wird. Sie können sich ansehen, wie Npgsql dies in NpgsqlOptions tut , das ISingletonOptions (oder CosmosSingletonOptions in EF Core) erweitert. @ajcvickers kann bestätigen, dass ich nichts
IIRC leider haben wir noch keinen Mechanismus, um DB-Kontextoptionen zu gerüsten, wie die Version implementiert würde. Im Moment keine Zeit, das Tracking-Problem zu finden, aber @bricelam kann dies bestätigen.
roji
am 23. Nov. 2019
Ich denke, wir haben es in #961 ähnlich implementiert, wo wir die Serverversion direkt vor dem Gerüstbau aus der Verbindung lesen und sie dann als IMySqlOptions Eigenschaft speichern (über unsere offizielle DbContextBuilder Erweiterung). Methode ServerVersion() ) und rufen Initialize() auf, sofern sie nicht bereits aus irgendeinem Grund eingerichtet wurde.
Anschließend verwenden wir ProviderCodeGenerator.GenerateProviderOptions() , um den Code für die Erweiterungsmethode ServerVersion() zu generieren.
Wir gehen also nicht mehr den Modellannotationsweg, den wir in der verschrotteten #932 PR versucht haben. Aber wir stellen mit dieser PR sicher, dass wir die gleiche Funktionalität bereitstellen, die wir mit #932 bereitstellen wollten, aber diesmal nur die bereits vorhandene ServerVersion() Erweiterungsmethode wiederverwenden.
lauxjpn
am 23. Nov. 2019
Wir müssen das Modell (oder nur seine Anmerkungen) in die Gerüstmethode des Anbieters einfließen lassen. Nachverfolgt von https://github.com/aspnet/EntityFrameworkCore/issues/10487
bricelam
am 23. Nov. 2019
Verwandte Themen
leobert1226
·
3Kommentare
neistow
·
4Kommentare
hainguyenthanh
·
3Kommentare
lebartha
·
3Kommentare
coultonluke
·
3Kommentare