Libelektra: yajl: le booléen d'Elektra n'est pas pris en charge

@kodebach est-il toujours possible que le plugin de type puisse être reconfiguré pour se normaliser à "vrai" au lieu de "1".

Non, ce n'est pas pris en charge par le plugin de type, je ne savais pas qu'il y avait un cas d'utilisation pour cela.

OMI, cela n'a pas non plus de sens. La manière Elektra de représenter un booléen est 0 et 1 . Si un format de stockage prend en charge les types, la conversion de la représentation Elektra à la représentation du format de stockage doit être effectuée par le plugin de stockage. En fin de compte, le plugin de stockage pour le format X devrait être le pont entre Elektra et le format X.

Le plus gros problème n'est-il pas non plus la restauration des valeurs? La restauration se fait dans presetstorage , et vous avez explicitement demandé que les valeurs soient toujours restaurées dans la représentation choisie par l'utilisateur, lors de la définition de la valeur. Cela signifie que si vous avez utilisé kdb set user/tests/yajl on dans votre exemple, le plugin yajl recevra la valeur on .

Ce dont nous avons réellement besoin ici, c'est d'un moyen de définir la représentation dans laquelle les valeurs sont restaurées, quelle que soit la manière dont l'utilisateur a défini la valeur. Cela pourrait être ajouté très facilement. Cependant, je ne suis pas sûr qu'il existe actuellement un moyen de spécifier la configuration d'un plugin, à partir d'un autre plugin. Cela signifie que l'utilisateur devra toujours configurer correctement type lors de l'utilisation de yajl .

que les valeurs sont toujours restaurées à la représentation choisie par l'utilisateur

Ce ne serait pas un problème car dans JSON la seule présentation disponible est true / false, donc l'utilisateur ne peut pas choisir.

Cela signifie que l'utilisateur devra toujours configurer correctement le type lors de l'utilisation de yajl.

Ce ne serait pas non plus un problème car yajl peut ajouter une configuration / doit reconfigurer le plugin de type.

La manière Elektra de représenter un booléen est 0 et 1. Si un format de stockage prend en charge les types, la conversion de la représentation Elektra à la représentation du format de stockage doit être effectuée par le plugin de stockage.

Oui, je suis entièrement d'accord. L'avantage de votre approche est qu'elle permettra également aux plugins intermédiaires (entre type et stockage) de voir la représentation correcte des booléens.

J'ai mis à jour le "Conseil de mise en œuvre" ci-dessus pour refléter cela.

@kodebach une autre question: JSON ne prend en charge que double / boolean / string. Est-il possible de dire au plugin de type que seuls ces 3 types sont autorisés?

Cela corrigerait également les types JSON mentionnés dans # 1092.

Ce ne serait pas un problème car dans JSON la seule présentation disponible est true / false, donc l'utilisateur ne peut pas choisir.

Ils ne peuvent pas choisir en JSON, mais ils peuvent choisir en utilisant kdb set

entre type et stockage

L'ordre devrait être comme ceci: getstorage , type , [other], type , setstorage , ce qui signifie qu'il ne devrait jamais y avoir de plugins entre les types et stockage.

J'ai mis à jour le "Conseil de mise en œuvre" ci-dessus pour refléter cela.

Il y a toujours le problème que, par exemple, kdb set user/tests/yajl on ne fonctionnera pas, sans modification de type , car dans ce cas type passera la valeur on au setstorage brancher.

JSON ne prend en charge que le double / booléen / chaîne. Est-il possible de dire au plugin de type que seuls ces 3 types sont autorisés?

Il ne devrait pas être difficile de restreindre les types autorisés via la configuration.

Ils ne peuvent pas choisir dans JSON, mais ils peuvent choisir lors de l'utilisation de kdb set

Ce qui est choisi dans kdb set ne peut pas être mémorisé de toute façon si le format de fichier ne le prend pas en charge.

Il y a toujours le problème que, par exemple, kdb set user / tests / yajl on ne fonctionnera pas, sans changement de type, car dans ce cas, type transmettra la valeur au plugin setstorage.

Pourquoi ne se transforme-t-il pas en "1" dans ce cas?

Il ne devrait pas être difficile de restreindre les types autorisés via la configuration.

Peut-être que cela n'a même pas d'importance. Cela fait-il une différence si le plugin de stockage ou le plugin de type dit qu'un type n'est pas autorisé? Ce serait bien si le tutoriel de stockage disait également quelque chose sur les types ( @sanssecours ?)

Cela fait-il une différence si le plugin de stockage ou le plugin de type dit qu'un type n'est pas autorisé?

Pas que je sache de. Il serait probablement encore mieux de signaler l'erreur dans le plugin de stockage, car l'utilisateur voit alors que le problème est l'utilisation de yajl non l'utilisation de type .

Pourquoi ne se transforme-t-il pas en "1" dans ce cas?

La procédure de normalisation / restauration peut être décrite par les cas suivants:

• Cas 1: La clé existait dans kdbGet et est inchangée entre kdbGet et kdbSet
  C'est le cas le plus simple et le plus évident. La valeur est normalisée en kdbGet et la valeur d'origine est restaurée en kdbSet , de sorte que le fichier de stockage sous-jacent reste inchangé (par rapport à la clé en question)
• Cas 2: La clé n'existait pas dans kdbGet
  Ici, nous normalisons la valeur pour vérifier le type, puis le restaurons immédiatement.
• Cas 3: La clé existait dans kdbGet , mais sa valeur a été modifiée entre kdbGet et kdbSet
  Ceci est essentiel comme le cas 2. keySetString supprime les métadonnées origvalue , donc pour le plugin type ce type de clé n'existait pas dans kdbGet .

Il y a un cas particulier. J'ai déjà ajouté des fonctionnalités qui pourraient être utilisées ici (j'ai oublié de l'ajouter aux infos / métadonnées):

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

Si yajl injecte les métadonnées check/boolean/true = true et check/boolean/false = false pour toutes les clés booléennes, toute la normalisation et la restauration devraient fonctionner comme prévu. Le plugin type acceptera alors les valeurs true , 1 , false et 0 pour les clés booléennes (dans get et set), mais il passera toujours true ou false au plugin setstorage. Le plugin yajl devrait toujours retourner 0 / 1 dans get et il devrait accepter true / false ainsi que 0 / 1 dans l'ensemble, pour qu'il fonctionne avec ou sans le plugin type .

Si nous choisissons de descendre de cette manière cependant, nous devons très bien le documenter, car le montage du plugin de type ne permettra plus d'utiliser des valeurs différentes pour les clés booléennes dans kdb set , car yajl secrètement remplace toute configuration donnée par l'utilisateur.

Pas que je sache de. Il serait probablement encore mieux de signaler l'erreur dans le plugin de stockage, car alors l'utilisateur voit que le problème est l'utilisation de yajl et non l'utilisation de type.

Exactement.

La procédure de normalisation / restauration peut être décrite par les cas suivants
[...] (j'ai oublié de l'ajouter aux infos / métadonnées)

Merci pour l'explication détaillée. Pouvez-vous ajouter ceci à notre documentation s'il vous plaît?

ne permettra plus d'utiliser des valeurs différentes pour les clés booléennes dans kdb set

Avec "config / needs", yajl peut s'assurer que le type est monté en utilisant "check / boolean / true = true et check / boolean / false = false".

Dois-je donc changer l'indication de mise en œuvre?

Avec "config / needs", yajl peut s'assurer que le type est monté en utilisant "check / boolean / true = true et check / boolean / false = false".

Vous avez mal compris, pour l'instant check/boolean/true et check/boolean/false doivent être définis comme métadonnées sur une clé individuelle, pas dans la configuration de type . Le support général au sein de la configuration devrait être ajouté (assez simple).

D'accord. Non, alors laissez-le tel quel. Il est plus logique de tout implémenter dans le plugin yajl.
J'ai ajouté comme indice de mise en œuvre:

Le plugin yajl doit:

• [] rend les valeurs "0" et "1" d'Elektra à false et true de JSON.
• [] échoue avec des erreurs de type si des types non pris en charge sont trouvés

@sanssecours pouvez-vous ajouter ces informations au tutoriel du plugin de stockage?

yajl doit également ajouter les métadonnées check/boolean/true = true et check/boolean/false = false à chaque clé avec type = boolean . Sinon, le problème pour kdb set /some/key on mentionné ci-dessus se produira.

yajl doit également ajouter les métadonnées

Est-ce également nécessaire si yajl ne vous donne toujours que "0" et "1" pour les booléens?

Oui, car le problème se produit lorsque l'utilisateur modifie la valeur de la clé après kdbGet . yajl n'a aucune influence sur cela.

Mais tant pis, nous avons quand même besoin de modifications du plugin type , car si l'utilisateur ajoute une nouvelle clé, les métadonnées ne seront pas présentes et la solution ne fonctionnera pas.

Nous avons donc besoin que le plugin de type soit disponible deux fois dans le chemin kdbSet pour que la normalisation fonctionne correctement? Pouvez-vous créer un problème?

Non. Avec # 2582 yajl (ou l'utilisateur) doit simplement s'assurer que la configuration pour type contient soit

• no booleans tableau et boolean/restore = #1
  ou
• a un tableau booleans qui contient "true" et "false" à la position #X et boolean/restore = #X

Je vais essayer de résoudre ce problème, mais j'ai une question.

Ne devrait-il pas suffire de définir type=boolean et type/boolean/restoreas=none sur une clé que j'analyse comme booléenne dans elektraYajlGet ? Ensuite, dans elektraYajlSet je devrais recevoir cette clé avec une valeur de 1 ou 0, non?

Mais je reçois toujours la valeur fournie par l'utilisateur

# 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
Est-il possible que dans ce cas la valeur soit toujours restaurée même si type/boolean/restoreas=none ?

/boolean/restoreas n'est pas un metakey pour des clés individuelles. Il fait partie de la configuration de l'instance du plugin type utilisé pour tout le point de montage.

Je pense qu'il devrait suffire d'ajouter config/needs = type/boolean/restoreas=none à l'en-tête de src/pluigns/yajl/README.md . (Au moins pour le montage via kdb mount )

Ajouter - infos/config/needs = type/boolean/restoreas=none semble être une erreur du compilateur.

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

Puis-je également définir la clé par programme? Je ne trouve pas de documentation sur la configuration d'un autre plugin.

Je pense que ça devrait être config/need non infos/config/needs . Je ne peux pas le vérifier pour le moment.

L'en-tête du README est transformé en lignes de keyNew , que vous incluez ensuite dans la méthode des plugins get . Vous pouvez y ajouter manuellement des éléments, en utilisant le README est préférable, car il fournit automatiquement la documentation.

Puis-je également définir la clé par programme?

Oui, ajoutez-le simplement à l'ensemble de clés de contrat. Par exemple, la ligne suivante montre comment YAML CPP configure le plugin type :

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

Merci à vous deux!

Avec # 3012, le plugin yajl a le comportement suivant.

Avec le plugin de type

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
}

Sans le plugin de type

Le plugin yajl devrait toujours retourner 0 / 1 dans get et il devrait accepter true / false ainsi que 0 / 1 dans set, pour qu'il fonctionne avec ou sans le plugin type .

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

Cela fait-il référence au moment où le plugin de type est monté ou sans?

Dans ce dernier cas, le comportement jusqu'à présent était qu'un avertissement soit émis.

 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

Je pense que c'est toujours bien, car sans le plugin de type, il ne devrait pas y avoir de vérification de type.

En fait, il devrait avertir (ou même échouer) sur tout sauf "1" ou "0". De plus, «vrai», «faux» ne sont pas les booléens d'Elektra.

Imho, le plugin yajl devrait avoir une dépendance "require" au plugin de type. (mais nous devons d'abord corriger le "nombre", car ce n'est pas l'un des types d'Elektra).

En fait, il devrait avertir (ou même échouer) sur tout sauf "1" ou "0". De plus, «vrai», «faux» ne sont pas les booléens d'Elektra.

@kodebach a écrit

Le plugin yajl doit toujours renvoyer 0/1 dans get et il doit accepter aussi bien true / false que 0/1 dans set, afin qu'il fonctionne avec ou sans le plugin de type.

C'est ce que j'autorise aussi «vrai» et «faux».

Imho, le plugin yajl devrait avoir une dépendance "require" au plugin de type. (mais nous devons d'abord corriger le "nombre", car ce n'est pas l'un des types d'Elektra).

Oui, je suis tout à fait d'accord sur la dépendance. Ensuite, nous pouvons supprimer le support pour "vrai" et "faux".

En ce qui concerne le problème de nombre: Yajl mappe le type de nombre à doubler, ce qui est bien, je pense. Et à partir d'une vérification rapide, le double type du plugin de type supporte également la notation E de json (ie 3.4e2 ).
Quel est selon vous le problème?

Quel est selon vous le problème?

Ahh, je vois maintenant que src / plugins / yajl / testmod_yajl.c 240-251 est commenté. Cela devrait être supprimé. (Il y a toujours une occurrence de nombre.)