AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Nullable VS Nullable

Ein Thema von WiPhi · begonnen am 9. Jan 2019 · letzter Beitrag vom 7. Feb 2019
Antwort Antwort
WiPhi

Registriert seit: 19. Feb 2015
90 Beiträge
 
Delphi 11 Alexandria
 
#1

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 07:49
Ich danke euch für die Anregungen.
Derzeit habe ich es so gelöst wie hoika es vorgeschlagen hat: Die Aurelis Unit als letztes einbinden. Ich prüfe demnächst noch, ob ich es sich lohnt den Aurelis-Typen durch meinen eigenen zu ersetzen.

Das Problem besteht wirklich darin, dass in der Spring-Unit alle Basis-Typen von Spring4D deklariert sind.

Z.B.: Ich benutze den Nullable-Spring nicht, möchte aber dennoch den TValue-Helper verwenden. (Konkret die Fähigkeit des Helpers um Werte zu konvertieren.)

Delphi-Quellcode:
uses
  Spring;
// <snip>
procedure Foo;
var
  x: String
  Value: TValue
begin
  Value := 20;
  x := Value.ToType<String>;
end;
Möchte ich jetzt aber eine Nullable-Konvertierung durchführen, registriere ich zuerst Aurelis-Nullable Konverter:
Delphi-Quellcode:
uses
  Spring.ValueConverters,
  Aurelius.Nullable;

// <snip>
TValueConverterFactory.RegisterConverter([SaemtlicheTypen], TypeInfo(Aurelius.Nullable<EntsprechenderTyp>), TTypeToNullableConverter); // und natürlich die Gegenrichtung
Besonders schön ist das die Klasse TTypeToNullableConverter nicht von mir, sondern auch aus Spring stammt und augenscheinlich mit dem Aurelius-Nullable klar kommt.

Anschließend kann ich Aurelius.Nullable-Konvertierungen durchführen:

Delphi-Quellcode:
uses
  Spring,
  Aurelius.Nullable;
// <snip>
procedure Foo;
var
  x: Nullable<String>
  Value: TValue;
begin
  Value := 20;
  x := Value.ToType<Nullable<String>>;
end;
Vielleicht hat jemand noch eine andere Idee, anonsten kann ich (und auch zukünftige Entwickler des Projekts) denk ich damit umgehen.
Wer sucht, der findet. Wer länger sucht, findet mehr.
  Mit Zitat antworten Zitat
freimatz

Registriert seit: 20. Mai 2010
1.490 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 07:53
Das Problem besteht wirklich darin, dass in der Spring-Unit alle Basis-Typen von Spring4D deklariert sind.
...
Vielleicht hat jemand noch eine andere Idee, anonsten kann ich (und auch zukünftige Entwickler des Projekts) denk ich damit umgehen.
Bei Spring4D vorstellig werden, sie mögen doch bitte eine eigene unit für die Nullable machen?
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.874 Beiträge
 
Delphi 11 Alexandria
 
#3

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 09:46
Spring4D beinhaltet auch ein ORM (MarshMallow)
Markus Kinzler
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.073 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 10:19
Ohne beide Typen je unter die Finger bekommen zu haben, aber kann man nicht je einen record helper schreiben, der zwischen den verschiedenen Typen automatisch konvertiert bei Zuweisung?
  Mit Zitat antworten Zitat
WiPhi

Registriert seit: 19. Feb 2015
90 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 12:01
Spring4D beinhaltet auch ein ORM (MarshMallow)
Hatte ich mir als aller erstes ORM angeschaut, jedoch fehlen mir darin wichtige Funktionen. Vor allem verbundene Primary Keys zu verwenden. Deswegen bin ich zu Aurelius gewechselt.

Ohne beide Typen je unter die Finger bekommen zu haben, aber kann man nicht je einen record helper schreiben, der zwischen den verschiedenen Typen automatisch konvertiert bei Zuweisung?
Das wäre meine Traumlösung mittels Implict Zuweisungen, jedoch lt. Delphi Hilfe http://docwiki.embarcadero.com/RADSt...oading_(Delphi) Note: Class and record helpers do not support operator overloading.

Da bin ich schon an der Deklaration gescheitert. Spring4D hat das irgendwie hinbekommen (s. TValue Helper), jedoch kam ich noch nicht dazu mir das genauer anzuschauen. Ehrlich gesagt ist das mit den Operanden-Überladen noch ziemliches Neuland für mich.
Wie müsste das dann ungefähr aussehen?

Danke für eure Anregungen
Wer sucht, der findet. Wer länger sucht, findet mehr.
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#6

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 12:38
Ich möchte nochmals darauf hinweisen, dass gerade hier bei der Einhaltung von SoC dieses Problem nicht wirklich existiert, bzw. an nur einer überschaubaren Stelle auftritt.

Die Entity-Klassen für Aurelius (oder jedes andere ORM-Framework) spiegeln 1:1 die SQL-Tabellen wieder und nur in den eher zufällig seltenen Fällen auch Anwendungs-Klassen.

Beispiel:
Delphi-Quellcode:
// Domain-Model
TAddress = record
  Street: string;
  PostalCode: string;
  City: string;
end;

TContact = record
  Id : Integer;
  Firstname: string;
  Lastname: string;
  Addresses: TArray<TAddress>;
end;
und nun die ORM-Klassen, damit das auch in eine Datenbank rein kann
Delphi-Quellcode:
// Entity-Model
TContact = class
  property Id: Integer;
  // Concurrency-Conflicts-Detection
  property Version: Integer;
  property Firstname: string;
  property Lastname: string;
end;

TContactAddress = class
  property ContactId: Integer;
  property Position: Integer;
  property Street: string;
  property PostalCode: string;
  property City: string;
end;
Obwohl sich in beiden Informationen zu einem Kontakt befinden gibt es dennoch unterschiedliche Ansprüche an das Layout. Um das Addresses-Array auch exakt wiederherstellen zu können benötigt man zusätzlich auch die Position. Oder zum Erkennen von Concurrency-Conflicts die Version. Damit will man sich aber auf der Anwendungsebene nicht herumschlagen, zumal dieses (Position) auch wiederum der relationalen Datenbank geschuldet ist. Bei einer NoSQL-Datenbank könnte man darauf (Position) wiederum verzichten, denn dort wird auch die Reihenfolge der Adressen gespeichert.

Geändert von Schokohase (10. Jan 2019 um 12:42 Uhr)
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.073 Beiträge
 
Delphi 10.4 Sydney
 
#7

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 12:50
Ohne beide Typen je unter die Finger bekommen zu haben, aber kann man nicht je einen record helper schreiben, der zwischen den verschiedenen Typen automatisch konvertiert bei Zuweisung?
Das wäre meine Traumlösung mittels Implict Zuweisungen, jedoch lt. Delphi Hilfe http://docwiki.embarcadero.com/RADSt...oading_(Delphi) Note: Class and record helpers do not support operator overloading.

Da bin ich schon an der Deklaration gescheitert. Spring4D hat das irgendwie hinbekommen (s. TValue Helper), jedoch kam ich noch nicht dazu mir das genauer anzuschauen. Ehrlich gesagt ist das mit den Operanden-Überladen noch ziemliches Neuland für mich.
Wie müsste das dann ungefähr aussehen?
Hm, so richtig will das nicht mit den generischen Operator für record helper.
Höchstens so ein "stumpfer" Ansatz mit Konvertierungsfunktionen scheint zu kompilieren:

Delphi-Quellcode:
unit Spring.Helper;

interface

uses
  Spring;

type

  TAureliusNullableType<T> = record

  end;

// TSpringNullable = Spring.Nullable<T>;
////
// NullableHelper<T> = record helper for TSpringNullable
// public
// class operator Implicit(const value: TAureliusNullableType<T>): Spring.Nullable<T>;
// end;

  TNullableConverter<T> = record
    class function ConvertSpring(const AureliusNullable: TAureliusNullableType<T>): Spring.Nullable<T>; static;
    class function ConvertAurelius(const SpringNullable: Spring.Nullable<T>): TAureliusNullableType<T>; static;
  end;



implementation

{ NullableHelper }

//class operator NullableHelper.Implicit(const value: TAureliusNullableType): Spring.Nullable<T>;
//begin
//end;

{ THelper<T> }

class function TNullableConverter<T>.ConvertAurelius(const SpringNullable: Spring.Nullable<T>): TAureliusNullableType<T>;
begin
  // Hausaufgabe
end;

class function TNullableConverter<T>.ConvertSpring(const AureliusNullable: TAureliusNullableType<T>): Spring.Nullable<T>;
begin
  // Hausaufgabe
end;

end.
  Mit Zitat antworten Zitat
WiPhi

Registriert seit: 19. Feb 2015
90 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 14:45
Entschuldige freimatz, deine Antwort hatte ich vorhin übersehen.
Bei Spring4D vorstellig werden, sie mögen doch bitte eine eigene unit für die Nullable machen?
Darüber habe ich auch schon nachgedacht, wollte aber erstmal sehen, ob es vielleicht eine einfache Lösung gibt, ohne in das Framework einzugreifen.

Ich möchte nochmals darauf hinweisen, dass gerade hier bei der Einhaltung von SoC dieses Problem nicht wirklich existiert, bzw. an nur einer überschaubaren Stelle auftritt.

Die Entity-Klassen für Aurelius (oder jedes andere ORM-Framework) spiegeln 1:1 die SQL-Tabellen wieder und nur in den eher zufällig seltenen Fällen auch Anwendungs-Klassen.
Anwendungs- und Datenhaltungsklassen sind strikt getrennt.

Ich denke bei meinem Fall geht es gerade um diese "überschaubare" Stelle: eine Import-Klasse, welche aus einer Datei in die Datenbank (sprich ORM) einliest. Diese Klasse muss zwangsläufig das Datenobjekt und somit auch den Aurelius-Nullable kennen. Weiterhin muss der Import bei Bedarf Werte konvertieren können (u.a. in Aurelius-Nullables). Ich möchte gar nicht den Spring Nullable verwenden, jedoch aber den TValue-Helper, welcher sich in der Spring-Unit befindet. Dummerweise befindet sich in dieser Unit auch der Spring Nullable.

Somit hat freimatz natürlich Recht: Wenn der Spring Nullable-Typ in einer separaten Unit liegen würde, hätte ich das Problem nicht.

Hm, so richtig will das nicht mit den generischen Operator für record helper.
Höchstens so ein "stumpfer" Ansatz mit Konvertierungsfunktionen scheint zu kompilieren:
Ja sowas hatte ich auch schon mal vor mir, war aber nicht besonders begeistert und habe es wieder verworfen. Wenn sollte das schon Implicit funktionieren.

Wie gesagt, derzeit funktioniert die Variante mit Aurelius Nullable als letzte Unit einbinden gut. Mittelfristig werde ich bei Gelegenheit mal bei Spring4D anfragen, ob der Nullable-Type in eine eigene Unit (so wie bei Aurelius ) wandern könnte.
OT: Da steht doch bald ein neues Release an? Wenn dort einige Major Änderungen gemacht welchen, wäre das ja eine Idee.
Wer sucht, der findet. Wer länger sucht, findet mehr.
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.073 Beiträge
 
Delphi 10.4 Sydney
 
#9

AW: Nullable VS Nullable

  Alt 10. Jan 2019, 15:36
Ich möchte gar nicht den Spring Nullable verwenden, jedoch aber den TValue-Helper, welcher sich in der Spring-Unit befindet. Dummerweise befindet sich in dieser Unit auch der Spring Nullable.

Somit hat freimatz natürlich Recht: Wenn der Spring Nullable-Typ in einer separaten Unit liegen würde, hätte ich das Problem nicht.
Delphi-Quellcode:
unit DeineUnitWoDuNichtSpringNullableNehmenWillst;

interface

uses
// Spring,
  SpringHelperUnitMitTypeForwarding;

implementation

end.
Delphi-Quellcode:
unit SpringHelperUnitMitTypeForwarding;

interface

uses
  Spring;

  TValueHelper = Spring.TValueHelper;

implementation

end.
Geht das?
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.045 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#10

AW: Nullable VS Nullable

  Alt 7. Feb 2019, 10:33
Besonders schön ist das die Klasse TTypeToNullableConverter nicht von mir, sondern auch aus Spring stammt und augenscheinlich mit dem Aurelius-Nullable klar kommt.
Die braucht man nicht - die von und nach Nullable<T> Konvertierung ist im TValueHelper direkt implementiert.
Diese benutzt aber die Implementierung, wie Spring4D sie hat und scheint nur mit Aurelius zu funktionieren, wird aber im Endeffekt Speicher korrumpieren. Bei Spring ist das interne FHasValue Feld ein String, damit auch lokale Variablen vom Typ Nullable<T> immer so initialisieren, dass sie signalisieren, null zu sein. Bei Aurelius ist es einfach ein Boolean. Hat auch Vorteile (kein expliziter Code für Init und Finalize für solche Variablen notwendig. Dafür sind sie erstmal in einem nicht definierten Zustand wie alle nicht gemanagten Wertetypen.

Wenn du ToType<Nullable<T>> für Aurelius Nullable<T> benutzt, wirst du dir Speicherlöcher schaffen und Speicher überschreiben, weil das intern auf das FHasValue Feld schreibt, was es für ein string Feld hält.

Aurelius ist im übrigen nicht die einzige Drittanbieter Komponente, die den Nullable Typen für sich entdeckt hat - da aber leider die Bereitschaft der meisten für Zusammenarbeit mit OpenSource Bibliotheken zusammen zu arbeiten gleich null ist, ist mir das dann auch egal, wenn der Klump nicht kompatibel ist. Ich wäre gern gewillt, bestimmte Teile so zu restrukturieren, dass sie gemeinsam mit anderen genutzt werden können, ohne dass jeder das Rad ein bisschen anders neu erfinden muss.

P.S. Ich werd mal zumindest schauen, dass er auch Aurelius Nullable korrekt konvertiert, ohne, dass es den Speicher zerfräst. Das sollte sich einfach genug machen lassen.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie ( 7. Feb 2019 um 10:45 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:29 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz