Libelektra: yajl: el booleano de Elektra no es compatible

@kodebach es posible que el complemento de tipo se pueda reconfigurar para normalizar a "verdadero" en lugar de "1".

No, esto no es compatible con el complemento de tipo, no sabía que había un caso de uso para esto.

En mi opinión, tampoco tiene sentido. La forma de Elektra de representar un valor booleano es 0 y 1 . Si un formato de almacenamiento admite tipos, la conversión de la representación de Elektra a la representación del formato de almacenamiento debe realizarse mediante el complemento de almacenamiento. Al final, el complemento de almacenamiento para el formato X debería ser el puente entre Elektra y el formato X.

Además, ¿no es el mayor problema la restauración de valores? La restauración se realiza en presetstorage , y usted solicitó explícitamente que los valores siempre se restauren a la representación elegida por el usuario, al establecer el valor. Esto significa que, si utilizó kdb set user/tests/yajl on en su ejemplo, el complemento yajl recibirá el valor on .

Lo que realmente necesitamos aquí es una forma de establecer la representación a la que se restauran los valores, independientemente de cómo el usuario establezca el valor. Esto podría agregarse muy fácilmente. Sin embargo, no estoy seguro de que exista actualmente una forma de especificar la configuración de un complemento, desde otro complemento. Lo que significa que el usuario aún tendría que configurar type correctamente al usar yajl .

que los valores siempre se restauran a la representación elegida por el usuario

Esto no sería un problema ya que en JSON la única presentación disponible es verdadera / falsa, por lo que el usuario no puede elegir.

Lo que significa que el usuario aún tendría que configurar el tipo correctamente al usar yajl.

Esto tampoco sería un problema porque yajl puede agregar una configuración / necesidades para reconfigurar el complemento de tipo.

La forma de Elektra de representar un booleano es 0 y 1. Si un formato de almacenamiento admite tipos, la conversión de la representación de Elektra a la representación del formato de almacenamiento debe realizarse mediante el complemento de almacenamiento.

Sí, estoy totalmente de acuerdo. La ventaja de su enfoque es que también permitirá que los complementos intermedios (entre el tipo y el almacenamiento) vean la representación correcta de los valores booleanos.

Actualicé la "Sugerencia de implementación" anterior para reflejar esto.

@kodebach otra pregunta: JSON solo admite doble / booleano / cadena. ¿Es posible decirle al complemento de tipo que solo se permiten estos 3 tipos?

Esto también arreglaría los tipos JSON mencionados en el # 1092.

Esto no sería un problema ya que en JSON la única presentación disponible es verdadera / falsa, por lo que el usuario no puede elegir.

No pueden elegir en JSON, pero pueden elegir cuando usan kdb set

entre tipo y almacenamiento

El orden debería ser así: getstorage , type , [otro], type , setstorage , lo que significa que nunca debería haber ningún complemento entre tipos y almacenaje.

Actualicé la "Sugerencia de implementación" anterior para reflejar esto.

Todavía existe el problema de que, por ejemplo, kdb set user/tests/yajl on no funcionará sin cambios en type , porque en este caso type pasará el valor on al conjunto de almacenamiento enchufar.

JSON solo admite doble / booleano / cadena. ¿Es posible decirle al complemento de tipo que solo se permiten estos 3 tipos?

No debería ser difícil restringir los tipos permitidos a través de config.

No pueden elegir en JSON, pero pueden elegir cuando usan kdb set

Lo que se elige en kdb set no se puede recordar de todos modos si el formato de archivo no lo admite.

Todavía existe el problema de que, por ejemplo, kdb set user / tests / yajl on no funcionará sin cambios en el tipo, porque en este caso el tipo pasará el valor al complemento setstorage.

¿Por qué no se transforma en "1" en este caso?

No debería ser difícil restringir los tipos permitidos a través de config.

Quizás ni siquiera importe. ¿Hay alguna diferencia si el complemento de almacenamiento o el complemento de tipo dice que un tipo no está permitido? Sería bueno si el tutorial de almacenamiento también dijera algo sobre los tipos (¿ @sanssecours ?)

¿Hay alguna diferencia si el complemento de almacenamiento o el complemento de tipo dice que un tipo no está permitido?

No que yo sepa. Probablemente sería incluso mejor plantear el error en el complemento de almacenamiento, porque entonces el usuario ve que el problema es el uso de yajl no el uso de type .

¿Por qué no se transforma en "1" en este caso?

El procedimiento de normalización / restauración se puede describir mediante los siguientes casos:

• Caso 1: La clave existía en kdbGet y no ha cambiado entre kdbGet y kdbSet
  Este es el caso más fácil y obvio. El valor se normaliza en kdbGet y el valor original se restaura en kdbSet , de modo que el archivo de almacenamiento subyacente permanece sin cambios (con la clave en cuestión)
• Caso 2: La clave no existía en kdbGet
  Aquí normalizamos el valor para verificar el tipo y luego lo restauramos inmediatamente.
• Caso 3: La clave existía en kdbGet , pero su valor se cambió entre kdbGet y kdbSet
  Esto es esencial al igual que en el Caso 2. keySetString elimina los metadatos origvalue , por lo que para el complemento type este tipo de clave no existía en kdbGet .

Hay un caso especial. Ya agregué funcionalidad que podría usarse aquí (olvidé agregarla a infos / metadata):

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

Si yajl inyecta los metadatos check/boolean/true = true y check/boolean/false = false para todas las claves booleanas, toda la normalización y restauración deberían funcionar según lo previsto. El complemento type aceptará los valores true , 1 , false y 0 para claves booleanas (en get y set), pero siempre pasará true o false al complemento setstorage. El complemento yajl aún debería devolver 0 / 1 en get y debería aceptar true / false así como 0 / 1 en conjunto, para que funcione con o sin el complemento type .

Sin embargo, si elegimos bajar de esta manera, tenemos que documentarlo muy bien, porque montar el complemento de tipo ya no permitirá usar valores diferentes para claves booleanas en kdb set , porque yajl secreto anula cualquier configuración dada por el usuario.

No que yo sepa. Probablemente sería incluso mejor plantear el error en el complemento de almacenamiento, porque entonces el usuario ve que el problema es el uso de yajl y no el uso de tipo.

Exactamente.

El procedimiento de normalización / restauración se puede describir mediante los siguientes casos
[...] (Olvidé agregarlo a infos / metadata)

Gracias por la explicación detallada. ¿Puede agregar esto a nuestra documentación, por favor?

ya no permitirá usar valores diferentes para claves booleanas en kdb set

Con "config / needs", yajl puede asegurarse de que el tipo se monte usando "check / boolean / true = true y check / boolean / false = false".

Entonces, ¿debería cambiar la sugerencia de implementación?

Con "config / needs", yajl puede asegurarse de que el tipo se monte usando "check / boolean / true = true y check / boolean / false = false".

Lo entendiste mal, ahora mismo check/boolean/true y check/boolean/false deben configurarse como metadatos en una clave individual, no en la configuración de type . Debería agregarse soporte general dentro de la configuración (bastante fácil).

Okay. No, entonces déjelo como está. Tiene más sentido implementar todo en el complemento yajl.
Agregué como sugerencia de implementación:

El complemento yajl debe:

• [] convierte los valores "0" y "1" de Elektra en JSON falso y verdadero.
• [] fallan con errores de tipo si se encuentran tipos no admitidos

@sanssecours ¿puedes agregar esta información al tutorial del complemento de almacenamiento?

yajl también tiene que agregar los metadatos check/boolean/true = true y check/boolean/false = false a cada clave con type = boolean . De lo contrario, se producirá el problema de kdb set /some/key on mencionado anteriormente.

yajl también tiene que agregar los metadatos

¿Es esto también necesario si yajl siempre le da solo "0" y "1" para los valores booleanos?

Sí, porque el problema ocurre cuando el usuario cambia el valor de la clave después de kdbGet . yajl no tiene ninguna influencia en eso.

Pero no importa eso, necesitamos cambios en el complemento type todos modos, porque si el usuario agrega una nueva clave, los metadatos no estarán presentes y la solución no funcionará.

Entonces, ¿necesitamos que el complemento de tipo esté disponible dos veces en la ruta kdbSet para que la normalización funcione correctamente? ¿Puedes crear un problema?

No. Con # 2582 yajl (o el usuario) solo necesita asegurarse de que la configuración para type contenga

• no booleans matriz y boolean/restore = #1
  o
• tiene una matriz booleans que contiene "true" y "false" en la posición #X y boolean/restore = #X

Intentaré arreglar esto, pero tengo una pregunta.

¿No debería ser suficiente establecer type=boolean y type/boolean/restoreas=none en una clave que analizo como booleana en elektraYajlGet ? Luego, en elektraYajlSet debería recibir esta clave con un valor de 1 o 0, ¿verdad?

Pero sigo recibiendo el valor proporcionado por el usuario

# 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
¿Es posible que en este caso el valor siempre se restaure incluso si type/boolean/restoreas=none ?

/boolean/restoreas no es una metaclave para claves individuales. Es parte de la configuración para la instancia del complemento type utilizado para todo el punto de montaje.

Creo que debería ser suficiente agregar config/needs = type/boolean/restoreas=none al encabezado de src/pluigns/yajl/README.md . (Al menos para montar a través de kdb mount )

Agregar - infos/config/needs = type/boolean/restoreas=none parece ser un error del compilador.

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

¿Puedo configurar la clave también mediante programación? No puedo encontrar documentación sobre cómo configurar otro complemento.

Creo que debería ser config/need no infos/config/needs . Sin embargo, no puedo verificarlo ahora mismo.

El encabezado del README se convierte en líneas de keyNew , que luego se incluyen en el método de los complementos get . Puede agregar cosas manualmente allí, se prefiere usar el archivo README, ya que proporciona documentación automáticamente.

¿Puedo configurar la clave también mediante programación?

Sí, solo agréguelo al conjunto de claves del contrato. Por ejemplo, la siguiente línea muestra cómo YAML CPP configura el complemento type :

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

¡Gracias a los dos!

Con # 3012, el complemento yajl tiene el siguiente comportamiento.

Con el complemento de tipo

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
}

Sin el complemento de tipo

El complemento yajl aún debería devolver 0 / 1 in get y debería aceptar true / false así como 0 / 1 en conjunto, para que funcione con o sin el complemento 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

¿Eso se refiere a cuando el complemento de tipo está montado o no?

En este último caso, el comportamiento hasta ahora era que se emite un aviso.

 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

Creo que esto todavía está bien, ya que sin el complemento de tipo, no debería haber verificación de tipo.

En realidad, debería advertir (o incluso fallar) sobre cualquier cosa excepto "1" o "0". Además, "verdadero", "falso" no son valores booleanos de Elektra.

En mi humilde opinión, el complemento yajl debería tener una dependencia "require" del complemento de tipo. (pero primero también necesitamos fijar el "número", ya que no es uno de los tipos de Elektra).

En realidad, debería advertir (o incluso fallar) sobre cualquier cosa excepto "1" o "0". Además, "verdadero", "falso" no son valores booleanos de Elektra.

@kodebach escribió

El complemento yajl debería devolver 0/1 en get y debería aceptar verdadero / falso así como 0/1 en el conjunto, para que funcione con o sin el complemento de tipo.

Eso es lo que también permito "verdadero" y "falso".

En mi humilde opinión, el complemento yajl debería tener una dependencia "require" del complemento de tipo. (pero primero también necesitamos fijar el "número", ya que no es uno de los tipos de Elektra).

Sí, estoy totalmente de acuerdo con la dependencia. Entonces podemos eliminar el soporte para "verdadero" y "falso".

En cuanto al problema de los números: Yajl asigna el tipo de número al doble, lo cual está bien, creo. Y al verificar rápidamente, el tipo doble del complemento de tipo también admite la notación electrónica de json (es decir, 3.4e2 ).
¿Cuál cree que es el problema?

¿Cuál cree que es el problema?

Ahh, ahora veo que src / plugins / yajl / testmod_yajl.c 240-251 está comentado. Esto debería eliminarse. (Todavía hay una ocurrencia de número).