TFDJSONDataSetsReader liefert immer das letzte DataSet

[Kostas]

Hallo Zusammen,

vorab: ich suche keine Lösung sondern berichte über zwei Bugs die ich gefunden habe, zumindest empfinde ich es als Bug.


------------Problem 1----------------
Ich habe eine TFDQuery SELECT * FROM &TableNamen WHERE UEBERTRAGEN = 1 dessen Tabellenname per Makro übergeben wird.
Insgesamt sind es fünf Tabellen die in ein TFDJSONDataSets geschrieben werden.
Ich gehe also in einer Schleife durch. Dabei setze ich den Tabellennamen und schreibe die Daten in das TFDJSONDataSets
über die Methode: TFDJSONDataSetsWriter.ListAdd(ExportFDJSONDataSets, TableName, qry); Die drei Parameter sind:
-ExportFDJSONDataSets das ist das TFDJSONDataSets
-TableName den eindeutige Tabellennamen
-qry immer das gleiche TFDQuery welches die Daten der aktuellen Datei darstellt.

ACHTUNG: Das Problem ist, ich übergebe immer das gleiche Object "qry" eigentlich sollte das keine Problem sein, ist es jedoch.
Deutlich wird es wenn man sich anschaut was exportiert wird. Der Objectname "qry" wird als "Table Name" exportiert und nicht wie erwartet,
nach meiner Vorgabe über "TableName"

Code:

 <Table Name="qry" SourceName="KONTAKTE" SourceID="1" TabID="0" EnforceConstraints="False" MinimumCapacity="50">

Das hat zur Folge, beim schreiben der DataSets ins TFDJSONDataSets, überschreibt das letzte DataSet alle DataSets da sie den gleichen Namen haben "qry"
Somit sind alle fünf DataSets mit dem gleichen Inhalt!
LDataSet := TFDJSONDataSetsReader.GetListValueByName(FJSONDataSets, TableName); //Auslesen über den Namen LDataSet := TFDJSONDataSetsReader.GetListValue(FJSONDataSets, I); //Auslesen über den Index Wenn ich jedoch für jede Query ein eigene TFDQuery verwende die auch jeweils einen anderen Namen hat, funktioniert das Auslesen einwandfrei.


------------Problem 2----------------
Wenn das TFDJSONDataSets erzeugt und noch kein DataSet per "TFDJSONDataSetsWriter.ListAdd" geschrieben wurde,
würde ich erwarten dass   TFDJSONDataSetsReader.GetListCount(FJSONDataSets) 0 zurückgibt.
Das ist nicht so, es kommt eine Exception dass kein DataSet vorhanden ist.

Wenn man den Source anschaut ist es klar, AList.FDataSets ist nil! Eigentlich sollte hier die zwei or Bedingung weg und nil zurückgegeben werden.
Die aufrufende Methode prüft bereits auf nil dieser Methode und gibt richtigerweise auch als Result := 0; zurück.

Delphi-Quellcode:

class function TFDJSONDataSetsReaderBase.GetPairList(
  const AList: TFDJSONDataSetsBase): TPairList;
begin
  if (AList = nil) or (AList.FDataSets = nil) then
    raise EFDDataListError.Create(sCantReadNilList);
  Result := AList.FDataSets;

end;

------------Problem 3----------------
Der erzeugte JSON Text ist zu geschwätzig. Meine fünf Tabellen habe ich als CSV exportiert, erste Zeile die Feldbezeichner und danach die Records.
Alle fünf Tabellen zusammen ergeben etwa 1300 Bytes. Exportiere ich aus den fünf Tabellen das JSON in ein File hat dieses File 15000 Bytes.
Dabei ist auffällig, zu jedem Feld bei jedem Record werden die Feldbezeichner mit exportiert. Auch weitere Daten werden exportiert. Z.B.
für jedes Feld werden stolze 17 Eigenschaften exportiert. Somit ist die eigentliche Stärke von JSON ausgehebelt wie ich finde.

Code:

"RowList":[{"RowID":0,"Original":{"KONTAKTID":700002,"PERSONID":700002,"KONTAKTTYP":1,"KONTAKT":"11111111111","UEBERTRAGEN":true}}]}]

Als Beispiel habe ich einen Datensatz exportiert. Die Nutzdaten sind "700002, 700002, 1, '11111111111', true"
Ihr könnt das JSON anzeigen lassen z.B.: mit dem Viewer: http://codebeautify.org/jsonviewer


Gruß Kostas

[Edit] getestet mit Delphi XE7 und XE8 SP1

[Sir Rufo]

Die eigentliche Stärke von JSON sieht man nicht, wenn man einfach nur eine platte Tabelle überträgt. Versuch mal mit CSV mehrere komplexe Dokumente zu übertragen, dann sieht man was JSON kann.

Mit einem Trecker den Vorgarten pflügen ist umständlicher als mit dem Spaten, aber bei 3ha Acker sieht das anders aus.

[Uwe Raabe]

Zitat von Kostas:

Das Problem ist, ich übergebe immer das gleiche Object "qry" eigentlich sollte das keine Problem sein, ist es jedoch.

Das ist genau das Problem! TFDJSONDataSetsWriter.ListAdd speichert die Instanz in der Liste. Die Umwandlung in JSON geschieht erst später. Aus diesem Grund musst du nicht nur jeweils eine separate FDQuery mitgeben, sondern diese müssen auch außerhalb deiner aktuellen Routine weiter existieren.

Zitat von Kostas:

Der Objectname "qry" wird als "Table Name" exportiert und nicht wie erwartet,
nach meiner Vorgabe über "TableName"

Code:

 <Table Name="qry" SourceName="KONTAKTE" SourceID="1" TabID="0" EnforceConstraints="False" MinimumCapacity="50">

Du liest das falsch: "Table" ist der XML-Tag und "Name" das Attribut. Es handelt sich hier um das interne Storage-Format der Klasse TFDDatSTable. Der von dir übergebene Name taucht an dieser Stelle gar nicht auf.

Zitat von Kostas:

Wenn ich jedoch für jede Query ein eigene TFDQuery verwende die auch jeweils einen anderen Namen hat, funktioniert das Auslesen einwandfrei.

Genau so war es auch gedacht.

Zitat von Kostas:

Wenn das TFDJSONDataSets erzeugt und noch kein DataSet per "TFDJSONDataSetsWriter.ListAdd" geschrieben wurde,
würde ich erwarten dass   TFDJSONDataSetsReader.GetListCount(FJSONDataSets) 0 zurückgibt.
Das ist nicht so, es kommt eine Exception dass kein DataSet vorhanden ist.

Das ist richtig! Ich empfehle einen Eintrag in quality.embarcadero.com

Zitat von Kostas:

Der erzeugte JSON Text ist zu geschwätzig. Meine fünf Tabellen habe ich als CSV exportiert, erste Zeile die Feldbezeichner und danach die Records.
Alle fünf Tabellen zusammen ergeben etwa 1300 Bytes. Exportiere ich aus den fünf Tabellen das JSON in ein File hat dieses File 15000 Bytes.
Dabei ist auffällig, zu jedem Feld bei jedem Record werden die Feldbezeichner mit exportiert. Auch weitere Daten werden exportiert. Z.B.
für jedes Feld werden stolze 17 Eigenschaften exportiert. Somit ist die eigentliche Stärke von JSON ausgehebelt wie ich finde.

Es gibt noch einen weiteren Nachteil: Dadurch, daß das interne Storage-Format übertragen wird, funktioniert das nur, wenn Sender und Empfänger mit derselben FireDAC-Version arbeiten. Das fällt insbesondere dann ins Gewicht, wenn man das JSON als externes, neutrales Speicherformat verwenden will. Das ist es hier nämlich nicht.

Allerdings ist das wohl kaum als Bug anzusehen. Allenfalls als ungeschickte Implementierung.

[jaenicke]

Zitat von Uwe Raabe:

Das ist genau das Problem! TFDJSONDataSetsWriter.ListAdd speichert die Instanz in der Liste. Die Umwandlung in JSON geschieht erst später. Aus diesem Grund musst du nicht nur jeweils eine separate FDQuery mitgeben, sondern diese müssen auch außerhalb deiner aktuellen Routine weiter existieren.

Wir haben das so gelöst, dass es eine TObjectList<TFDQuery> in der Servermethodenklasse gibt, die jeweils beim nächsten Aufruf der Methode zuerst geleert wird.

[Uwe Raabe]

Zitat von jaenicke:

Wir haben das so gelöst, dass es eine TObjectList<TFDQuery> in der Servermethodenklasse gibt, die jeweils beim nächsten Aufruf der Methode zuerst geleert wird.

So mache ich das in der Regel auch. Alternativ, wenn die Servermethodenklasse ein Datenmodul ist und natürlich wenn es praktikabel ist, kann man die Komponenten auch auf das Datenmodul legen. Das existiert immer über den gesamten Remote-Aufruf.

[jaenicke]

Zitat von Uwe Raabe:

Alternativ, wenn die Servermethodenklasse ein Datenmodul ist und natürlich wenn es praktikabel ist, kann man die Komponenten auch auf das Datenmodul legen.

In unserem Fall werden die zu ladenden Tabellen als SQL-Texte an die Servermethode übergeben. Deshalb ging das dort nicht.

[Kostas]

Zitat von Sir Rufo:

Die eigentliche Stärke von JSON sieht man nicht, wenn man einfach nur eine platte Tabelle überträgt. Versuch mal mit CSV mehrere komplexe Dokumente zu übertragen, dann sieht man was JSON kann.

Mit einem Trecker den Vorgarten pflügen ist umständlicher als mit dem Spaten, aber bei 3ha Acker sieht das anders aus.

Hallo Sir Rufo,
JSON hat die Eigenschaft die Feldnamen eine Section zu übertragen und die Records jeweils ohne Feldnamen. Darauf war
mein Kommentar gerichtet. Ich vergleiche XML mit JSON. Bei XML müssen die Feldnamen angegeben werden aber nicht in JSON.

Gruß Kostas

[Kostas]

Hallo Zusammen,

Wenn ich eine TFDQuery über SaveToFile(File, sfXML) ein XML schreibe,
beinhaltet das XML auch alle weitere Information dich auch in JSON enthalten sind.
Würde das bedeuten dass das XML nicht kompatibel wäre bei unterschiedlichen FireDac Versionen
oder ist das nur bei JSON?

Gruß Kostas

[jaenicke]

Ich habe es nicht ausprobiert, aber ich gehe davon aus, dass auch das nicht kompatibel sein muss.

[Uwe Raabe]

Der Unterschied zum CSV-Ansatz ist eher, daß FireDAC hier Objekte überträgt und nicht nur die reinen Inhalte eines DataSets. Damit werden insbesondere auch interne Zustände und falls vorhanden auch unterschiedliche Versionen der DataRows (Original, Current und Proposed) übertragen. Am Zielort entsteht so mehr oder weniger eine exakte Kopie der FDQuery-Instanz. Diese Art der Serialisierung ist halt bereits vorhanden ist und muss für JSON-Reflect nicht speziell für DataSets neu implementiert werden.

Andererseits hindert dich aber auch niemand daran, aus dem DataSet eine CSV-Repräsentation zu machen, diese zu übertragen und am Ziel in ein anderes DataSet einzulesen. Die BatchMove-Funktionalität in FireDAC kann dort sicher Hilfe leisten.