Libelektra: yajl: Elektras Boolescher Wert wird nicht unterstützt

@kodebach ist dies immer noch möglich, dass das Typ-Plugin neu konfiguriert werden kann, um auf "true" anstelle von "1" zu normalisieren.

Nein, dies wird vom Typ-Plugin nicht unterstützt. Ich wusste nicht, dass es dafür einen Anwendungsfall gibt.

IMO macht es auch keinen Sinn. Die Elektra-Art, einen Booleschen 0 darzustellen, ist 1 . Wenn ein Speicherformat Typen unterstützt, sollte die Konvertierung von der Elektra-Darstellung in die Darstellung des Speicherformats über das Speicher-Plugin erfolgen. Am Ende sollte das Speicher-Plugin für Format X die Brücke zwischen Elektra und Format X sein.

Ist das größere Problem nicht auch die Wiederherstellung von Werten? Die Wiederherstellung erfolgt in presetstorage , und Sie haben ausdrücklich angefordert, dass die Werte beim Festlegen des Werts immer in der vom Benutzer ausgewählten Darstellung wiederhergestellt werden. Das bedeutet , wenn Sie verwendet kdb set user/tests/yajl on in Ihrem Beispiel, die yajl Plugin wird den Wert erhalten on .

Was wir hier tatsächlich brauchen, ist eine Möglichkeit, die Darstellung festzulegen, auf die Werte wiederhergestellt werden, unabhängig davon, wie der Benutzer den Wert festgelegt hat. Dies könnte sehr leicht hinzugefügt werden. Ich bin mir jedoch nicht sicher, ob es derzeit eine Möglichkeit gibt, die Konfiguration für ein Plugin von einem anderen Plugin aus anzugeben. Dies bedeutet, dass der Benutzer type korrekt konfigurieren muss, wenn er yajl .

Diese Werte werden immer in der vom Benutzer gewählten Darstellung wiederhergestellt

Dies wäre kein Problem, da in JSON die einzige verfügbare Präsentation wahr / falsch ist, sodass der Benutzer keine Auswahl treffen kann.

Dies bedeutet, dass der Benutzer den Typ bei Verwendung von yajl weiterhin korrekt konfigurieren muss.

Dies wäre auch kein Problem, da yajl eine Konfiguration hinzufügen kann / muss, um das Typ-Plugin neu zu konfigurieren.

Die Elektra-Methode zur Darstellung eines Booleschen Werts ist 0 und 1. Wenn ein Speicherformat Typen unterstützt, sollte die Konvertierung von der Elektra-Darstellung in die Darstellung des Speicherformats über das Speicher-Plugin erfolgen.

Ja, ich stimme voll und ganz zu. Der Vorteil Ihres Ansatzes besteht darin, dass auch Zwischen-Plugins (zwischen Typ und Speicher) die korrekte Darstellung von Booleschen Werten sehen können.

Ich habe den "Implementierungshinweis" oben aktualisiert, um dies widerzuspiegeln.

@kodebach eine andere Frage: JSON unterstützt nur double / boolean / string. Kann man dem Typ-Plugin sagen, dass nur diese 3 Typen erlaubt sind?

Dies würde auch die in # 1092 erwähnten JSON-Typen beheben.

Dies wäre kein Problem, da in JSON die einzige verfügbare Präsentation wahr / falsch ist, sodass der Benutzer keine Auswahl treffen kann.

Sie können nicht in JSON auswählen, aber sie können auswählen, wenn kdb set

zwischen Typ und Speicher

Die Bestellung sollte folgendermaßen aussehen: getstorage , type , [andere], type , setstorage , was bedeutet, dass es niemals Plugins zwischen den Typen geben sollte und Lagerung.

Ich habe den "Implementierungshinweis" oben aktualisiert, um dies widerzuspiegeln.

Es gibt immer noch das Problem, dass zB kdb set user/tests/yajl on ohne Änderungen an type nicht funktioniert, da in diesem Fall type den Wert on an den Setstorage übergeben Plugin.

JSON unterstützt nur double / boolean / string. Kann man dem Typ-Plugin sagen, dass nur diese 3 Typen erlaubt sind?

Es sollte nicht schwierig sein, die zulässigen Typen über die Konfiguration einzuschränken.

Sie können nicht in JSON auswählen, aber sie können auswählen, wenn kdb set verwendet wird

Was in kdb set kann ohnehin nicht gespeichert werden, wenn das Dateiformat dies nicht unterstützt.

Es gibt immer noch das Problem, dass zdb set user / tests / yajl on ohne Änderungen am Typ nicht funktioniert, da in diesem Fall type den Wert an das setstorage-Plugin weiterleitet.

Warum wird es in diesem Fall nicht in "1" umgewandelt?

Es sollte nicht schwierig sein, die zulässigen Typen über die Konfiguration einzuschränken.

Vielleicht spielt es gar keine Rolle. Macht es einen Unterschied, ob das Speicher-Plugin oder das Typ-Plugin besagt, dass ein Typ nicht zulässig ist? Es wäre gut, wenn das Speicher-Tutorial auch etwas über Typen aussagen würde ( @sanssecours ?)

Macht es einen Unterschied, ob das Speicher-Plugin oder das Typ-Plugin besagt, dass ein Typ nicht zulässig ist?

Nicht, dass ich davon Wüste. Es wäre wahrscheinlich sogar noch besser, den Fehler im Speicher-Plugin auszulösen, da der Benutzer dann sieht, dass das Problem die Verwendung von yajl nicht die Verwendung von type .

Warum wird es in diesem Fall nicht in "1" umgewandelt?

Das Normalisierungs- / Wiederherstellungsverfahren kann durch die folgenden Fälle beschrieben werden:

• Fall 1: Der Schlüssel existierte in kdbGet und ist unverändert zwischen kdbGet und kdbSet
  Dies ist der einfachste und offensichtlichste Fall. Der Wert wird in kdbGet normalisiert und der ursprüngliche Wert in kdbSet wiederhergestellt, sodass die zugrunde liegende Speicherdatei unverändert bleibt (für den betreffenden Schlüssel).
• Fall 2: Der Schlüssel war in kdbGet nicht vorhanden
  Hier normalisieren wir den Wert, um den Typ zu überprüfen und ihn dann sofort wiederherzustellen.
• Fall 3: Der Schlüssel war in kdbGet , aber sein Wert wurde zwischen kdbGet und kdbSet geändert
  Dies ist genauso wichtig wie in Fall 2. keySetString entfernt die origvalue Metadaten, sodass diese Art von Schlüssel für das type Plugin in kdbGet nicht vorhanden war .

Es gibt einen Sonderfall. Ich habe bereits Funktionen hinzugefügt, die hier verwendet werden könnten (ich habe vergessen, sie zu Infos / Metadaten hinzuzufügen):

https://github.com/ElektraInitiative/libelektra/blob/6e609f7e78039db188e32d32d2ea13908c0abe38/src/plugins/type/README.md#L84 -L88

Wenn yajl die Metadaten check/boolean/true = true und check/boolean/false = false für alle booleschen Schlüssel einfügt, sollten alle Normalisierungen und Wiederherstellungen wie beabsichtigt funktionieren. Das type Plugin akzeptiert dann die Werte true , 1 , false und 0 für boolesche Schlüssel (in get und set). Es werden jedoch immer true oder false an das setstorage-Plugin übergeben. Das yajl Plugin sollte weiterhin 0 / 1 in get zurückgeben und true / false sowie 0 akzeptieren 1 im Set, so dass es mit oder ohne das Plugin type funktioniert.

Wenn wir uns jedoch für diesen Weg entscheiden, müssen wir ihn sehr gut dokumentieren, da durch das Mounten des Typ-Plugins keine unterschiedlichen Werte mehr für Boolesche Schlüssel in kdb set , da yajl heimlich überschreibt alle vom Benutzer angegebenen Konfigurationen.

Nicht, dass ich davon Wüste. Es wäre wahrscheinlich sogar noch besser, den Fehler im Speicher-Plugin auszulösen, da der Benutzer dann sieht, dass das Problem die Verwendung von yajl und nicht die Verwendung von type ist.

Genau.

Das Normalisierungs- / Wiederherstellungsverfahren kann in den folgenden Fällen beschrieben werden
[...] (Ich habe vergessen, es zu Infos / Metadaten hinzuzufügen)

Vielen Dank für die ausführliche Erklärung. Können Sie dies bitte zu unserer Dokumentation hinzufügen?

erlaubt nicht mehr, unterschiedliche Werte für Boolesche Schlüssel in kdb set zu verwenden

Mit "config / need" kann yajl sicherstellen, dass der Typ mit "check / boolean / true = true und check / boolean / false = false" gemountet wird.

Soll ich also den Implementierungshinweis ändern?

Mit "config / need" kann yajl sicherstellen, dass der Typ mit "check / boolean / true = true und check / boolean / false = false" gemountet wird.

Sie haben es falsch verstanden, jetzt müssen check/boolean/true und check/boolean/false als Metadaten für einen einzelnen Schlüssel festgelegt werden, nicht in der Konfiguration von type . Allgemeine Unterstützung innerhalb der Konfiguration müsste hinzugefügt werden (einfach genug).

OK. Nein, dann lass es wie es ist. Es ist sinnvoller, alles im yajl-Plugin zu implementieren.
Ich habe als Implementierungshinweis hinzugefügt:

Das Yajl-Plugin muss:

• [] Rendern Sie Elektras "0" - und "1" -Werte zu JSONs "false" und "true".
• [] schlägt mit Typfehlern fehl, wenn nicht unterstützte Typen gefunden werden

@sanssecours Kannst du diese Informationen zum Speicher-Plugin-Tutorial hinzufügen?

yajl außerdem die Metadaten check/boolean/true = true und check/boolean/false = false zu jedem Schlüssel mit type = boolean hinzufügen. Andernfalls tritt das oben erwähnte Problem für kdb set /some/key on auf.

yajl muss auch die Metadaten hinzufügen

Wird dies auch benötigt, wenn yajl Ihnen immer nur "0" und "1" für Boolesche Werte geben würde?

Ja, da das Problem auftritt, wenn der Benutzer den Schlüsselwert nach kdbGet ändert. yajl hat keinen Einfluss darauf.

Aber egal, wir müssen sowieso Änderungen am type Plugin vornehmen, denn wenn der Benutzer einen neuen Schlüssel hinzufügt, sind die Metadaten nicht vorhanden und die Lösung funktioniert nicht.

Das Typ-Plugin muss also zweimal im Pfad kdbSet verfügbar sein, damit die Normalisierung ordnungsgemäß funktioniert. Können Sie ein Problem erstellen?

Nein. Bei # 2582 yajl (oder dem Benutzer) muss nur sichergestellt werden, dass die Konfiguration für type entweder enthält

• kein booleans Array und boolean/restore = #1
  oder
• hat ein booleans Array, das "true" und "false" an Position #X und boolean/restore = #X

Ich werde versuchen, das zu beheben, habe aber eine Frage.

Sollte es nicht ausreichen, type=boolean und type/boolean/restoreas=none auf einen Schlüssel zu setzen, den ich in elektraYajlGet als boolesch analysiere? Dann sollte ich in elektraYajlSet diesen Schlüssel mit einem Wert von 1 oder 0 erhalten, oder?

Aber ich erhalte immer noch den vom Benutzer angegebenen Wert

# kdb mount conf.json user/tests/yajl yajl type
# kdb set user/tests/yajl 1
Set string to "1"
# kdb setmeta user/tests/yajl type boolean
# kdb set user/tests/yajl false
Sorry, 1 warning was issued ;(
    Sorry, module yajl issued the warning C03200:
    Validation Semantic: Got boolean which is neither true nor false
Set string to "false"

Case 2: The Key didn't exist in `kdbGet`
  Here we normalize the value to verify the type and then restore it immediately.

@ Kodebach
Ist es möglich, dass in diesem Fall der Wert immer wiederhergestellt wird, auch wenn type/boolean/restoreas=none ?

/boolean/restoreas ist kein Metakey für einzelne Schlüssel. Es ist Teil der Konfiguration für die Instanz des Plugins type das für den gesamten Mountpoint verwendet wird.

Ich denke, es sollte ausreichen, config/needs = type/boolean/restoreas=none zum Header von src/pluigns/yajl/README.md hinzuzufügen. (Zumindest für die Montage über kdb mount )

Das Hinzufügen von - infos/config/needs = type/boolean/restoreas=none scheint ein Compilerfehler zu sein.

/elektra/build/src/plugins/yajl/readme_yajl.c:11:55: error: expected ‘)’ before ‘keyNew’
 "- infos/config/needs = type/boolean/restoreas=none\n"
                                                       ^
                                                       )

Kann ich den Schlüssel auch programmgesteuert einstellen? Ich kann keine Dokumentation zum Konfigurieren eines anderen Plugins finden.

Ich denke, es sollte nur config/need nicht infos/config/needs . Ich kann es momentan jedoch nicht überprüfen.

Der Header der README wird in Zeilen von keyNew , die Sie dann in die Plugins get -Methode aufnehmen. Sie können dort manuell Inhalte hinzufügen. Die Verwendung der README-Datei wird bevorzugt, da diese automatisch die Dokumentation bereitstellt.

Kann ich den Schlüssel auch programmgesteuert einstellen?

Ja, fügen Sie es einfach dem Vertragsschlüsselsatz hinzu. Die folgende Zeile zeigt beispielsweise, wie YAML CPP das Plugin type konfiguriert:

https://github.com/ElektraInitiative/libelektra/blob/5519cb8066a096215a3701ca3d8c02fcebe54914/src/plugins/yamlcpp/yamlcpp.cpp#L44
.

Danke euch beiden!

Mit # 3012 hat das yajl-Plugin das folgende Verhalten.

Mit dem Typ Plugin

kdb mount conf.json user/tests/yajl yajl type
kdb set user/tests/yajl 1
kdb get user/tests/yajl
#> 1
kdb setmeta user/tests/yajl type boolean
kdb set user/tests/yajl on
kdb get user/tests/yajl
#> 1
kdb set user/tests/yajl/subkey disable
kdb setmeta user/tests/yajl/subkey type boolean
kdb get user/tests/yajl/subkey
#> 0

cat `kdb file user/tests/yajl`
{
    "___dirdata": true,
    "subkey": true
}

Ohne das Typ Plugin

Das yajl Plugin sollte weiterhin 0 / 1 in get zurückgeben und true / false sowie 0 akzeptieren 1 im Set, so dass es mit oder ohne das Plugin type funktioniert.

kdb mount conf.json user/tests/yajl yajl
kdb set user/tests/yajl 1
kdb getmeta user/tests/yajl type
#> boolean
kdb set user/tests/yajl false
kdb getmeta user/tests/yajl type
#> boolean
kdb get user/tests/yajl
#> 0

# Without the type plugin, 'on' is mapped to a string and a warning is emitted.
kdb set user/tests/yajl on
#> RET: 2

* fail with type errors if non-supported types are found

Bezieht sich das darauf, wann das Typ-Plugin gemountet ist oder nicht?

In diesem letzten Fall war das bisherige Verhalten, dass eine Warnung ausgegeben wird.

 Sorry, 1 warning was issued ;(
    Sorry, module yajl issued the warning C03200:
    Validation Semantic: Got boolean which is neither 1 or true nor 0 or false

Ich denke, das ist immer noch in Ordnung, da es ohne das Typ-Plugin keine Typprüfung geben sollte.

Eigentlich sollte es vor allem außer "1" oder "0" warnen (oder sogar scheitern). Auch "wahr", "falsch" sind nicht Elektras Boolesche Werte.

Imho, das yajl-Plugin sollte eine "erfordernde" Abhängigkeit vom Typ-Plugin haben. (aber zuerst müssen wir auch die "Nummer" festlegen, da es sich nicht um einen Elektra-Typ handelt).

Eigentlich sollte es vor allem außer "1" oder "0" warnen (oder sogar scheitern). Auch "wahr", "falsch" sind nicht Elektras Boolesche Werte.

@kodebach schrieb

Das yajl-Plugin sollte weiterhin 0/1 in get zurückgeben und true / false sowie 0/1 in set akzeptieren, damit es mit oder ohne Typ-Plugin funktioniert.

Das erlaube ich auch "wahr" und "falsch".

Imho, das yajl-Plugin sollte eine "erfordernde" Abhängigkeit vom Typ-Plugin haben. (aber zuerst müssen wir auch die "Nummer" festlegen, da es sich nicht um einen Elektra-Typ handelt).

Ja, ich stimme der Abhängigkeit voll und ganz zu. Dann können wir die Unterstützung für "true" und "false" entfernen.

In Bezug auf das Nummernproblem: Yajl ordnet den Nummerntyp dem Double zu, was meiner Meinung nach in Ordnung ist. Und von der schnellen Überprüfung unterstützt der Doppeltyp des Typ-Plugins auch die E-Notation von json (dh 3.4e2 ).
Was sehen Sie als Problem?

Was sehen Sie als Problem?

Ahh, ich sehe jetzt, dass src / plugins / yajl / testmod_yajl.c 240-251 auskommentiert ist. Dies sollte entfernt werden. (Es gibt immer noch ein Vorkommen von Zahlen.)