TFDJSONDataSetsReader liefert immer das letzte DataSet

[Kostas]

Hallo Uwe,

ich verwende aus einem andere Thread deine zwei Methoden um ein FDDataSet als JSON zu exportieren.

Sorgen macht mir deine Aussage dass in späteren Version das JSON? String nicht kompatibel sein könnte
allerdings war hier die Rede vom binary Format. In meinem Fall werden die JSON String in eine DB als Text
abgelegt. Der Anwender kann irgendwann auch nach einem Jahr das Paket anfordern. Dabei wird der JSON Text
in eine FDMemTable geschrieben und verarbeitet.

Weil es wichtig ist, wie wahrscheinlich könnte es sein dass der gespeicherte JSON Text nicht in eine FDMemTable
geschrieben werden kann?

Delphi-Quellcode:

function DataSetToJSON(Source: TFDDataSet): string;
var
   stream: TStringStream;
begin
   stream := TStringStream.Create;
   try
     Source.Open;
     Source.FetchAll;
     Source.SaveToStream(stream, TFDStorageFormat.sfJSON);
     result := stream.DataString;
   finally
     stream.Free;
   end;
end;

procedure JSONToDataSet(const Source: string; Target: TFDDataSet);
var
   stream: TStringStream;
begin
   stream := TStringStream.Create(Source);
   try
     Target.LoadFromStream(stream, TFDStorageFormat.sfJSON);
   finally
     stream.Free;
   end;
end;

Gruß Kostas

[Uwe Raabe]

Zitat von Kostas:

Sorgen macht mir deine Aussage dass in späteren Version das JSON? String nicht kompatibel sein könnte
allerdings war hier die Rede vom binary Format. In meinem Fall werden die JSON String in eine DB als Text
abgelegt. Der Anwender kann irgendwann auch nach einem Jahr das Paket anfordern. Dabei wird der JSON Text
in eine FDMemTable geschrieben und verarbeitet.

Weil es wichtig ist, wie wahrscheinlich könnte es sein dass der gespeicherte JSON Text nicht in eine FDMemTable
geschrieben werden kann?

Die Implementierung bei SaveToStream und LoadFromStream ist innerhalb der jeweiligen Objekte untergebracht. Dabei werden beim Save im Wesentlichen die Objekteigenschaften geschrieben, die vom Default abweichen (ähnlich wie bei einer DFM-Datei). Beim Load wird dieselbe Reihenfolge der Eigenschaften verwendet, wobei da halt geprüft wird, ob das erwartete Property tatsächlich im Storage an dieser Stelle drin steht; falls nicht, wird der Defaultwert verwendet. Solange die Reihenfolge und Typen der Eigenschaften im Storage nicht geändert wird, sollte ein älteres Storageformat somit lesbar sein.

Ergänzend wird auch eine StreamVersion im Storage verwaltet, die als Konstante im FireDAC hinterlegt ist. Wenn das konsequent berücksichtigt wird (von EMBA), ist zumindest eine Abwärtskompatibilität (neuere FireDAC können ältere Storages lesen) gegeben. Umgekehrt ist das mit Sicherheit nicht so. In der Vergangenheit (AnyDAC) war das zumindest schon mal ein Problem.

Für dein Speicherproblem sind Probleme dieser Art wohl unwahrscheinlich, wenn auch nicht ausgeschlossen. Es ist ja durchaus möglich, daß der Support sehr alter Formate irgendwann entfernt wird (muss ja alles gepflegt werden). Natürlich sind auch Fehler bei der Interpretation möglich. Es ist sehr unwahrscheinlich, daß der Import älterer Formate durch ausreichend Tests abgedeckt ist. Willst du auf Nummer-Sicher gehen und es kommt dir wirklich nur auf die enthaltenen Daten an, dann wäre ein reiner Text-Export/Import á la CSV wohl die bessere Wahl (KISS, selbst wenn die Implementierung dadurch komlexer wird).

Was sicher problematisch wird, ist eine Kommunikation zwischen Client und Server mit unterschiedlichen Stream-Formaten. Für den Fall, daß XE8+ ein neues Stream-Format einführt, dann müssen eventuell sowohl der Server als auch alle Clients mit derselben Version compiliert werden. Sonst kann zumindest einer vielleicht das Stream-Format des anderen nicht lesen. Das kann bei vielen Mobile-Clients, die irgendwo unkontrolliert in der Weltgeschichte rumschwirren schon eine anspruchsvolle Aufgabe werden.

[Kostas]

Tausend Dank Uwe für die sehr ausführliche Antwort.

In meinem Fall, kann ich dafür sorgen dass die Clients immer aktuell sind, ansonsten können sie einfach nicht senden, das ist völlig unkritisch.
Die gespeicherten Datenpakete werde ich riskieren und als JSON Text in die DB ablegen. Etwa 80% der Datenpakete beinhalten an die 15 Tabellen mit
insgesamt ca. 100 Datensätzen. Das ist schnell übertragen. Übrigens, ich habe heute eine Tabelle als JSON String mit 500.000 Datensätzen per DataSnap vom Client zum Server einfach über eine Methode als Parameter vom Typ String übertragen und am Server den String in ein StringStream gepackt und in die MemTable
importiert. Danach gleich als JSON wieder rausgeschrieben. Das File war 160MB groß es hat einwandfrei funktioniert. Solche Datenpakete muss ich nie übertragen.
Da in der DB der content JSON oder auch XML sein kann, habe ich den Vorteil dass ich es direkt in die MemTable aus der DB einlesen kann.
Falls sich wirklich die Struktur ändern sollte, kann ich alle Pakete auslesen und mit einem Tool welches ich dann schreiben würde in das neue Format konvertieren und wieder zurückschreiben. Vermutlich wird das nicht so oft vorkommen.

Du hast mir sehr geholfen, besten Dank Uwe.
Dir noch eine schöne Zeit.

Gruß Kostas