Libelektra: yajl: booleano de Elektra não suportado

@kodebach ainda é possível que o plugin de tipo possa ser reconfigurado para normalizar para "verdadeiro" em vez de "1".

Não, isso não é suportado pelo plugin de tipo, eu não sabia que havia um caso de uso para isso.

IMO, também não faz sentido. A maneira Elektra de representar um booleano é 0 e 1 . Se um formato de armazenamento suportar tipos, a conversão da representação Elektra para a representação do formato de armazenamento deve ser feita pelo plugin de armazenamento. No final, o plugin de armazenamento para o formato X deve ser a ponte entre Elektra e o formato X.

O maior problema também não é a restauração de valores? A restauração é feita em presetstorage , e você solicitou explicitamente, que os valores sejam sempre restaurados para a representação escolhida pelo usuário, ao definir o valor. Isso significa que, se você usou kdb set user/tests/yajl on em seu exemplo, o plug-in yajl receberá o valor on .

O que realmente precisamos aqui é uma maneira de definir a representação para a qual os valores são restaurados, independentemente de como o usuário definiu o valor. Isso pode ser adicionado facilmente. No entanto, não tenho certeza se existe atualmente uma maneira de especificar a configuração de um plug-in de outro plug-in. Significando que o usuário ainda teria que configurar type corretamente ao usar yajl .

que os valores são sempre restaurados para a representação escolhida pelo usuário

Isso não seria um problema, pois em JSON a única apresentação disponível é verdadeiro / falso, portanto o usuário não pode escolher.

Isso significa que o usuário ainda terá que configurar o tipo corretamente ao usar yajl.

Isso também não seria nenhum problema porque yajl pode adicionar um config / need para reconfigurar o plugin de tipo.

A maneira Elektra de representar um booleano é 0 e 1. Se um formato de armazenamento suportar tipos, a conversão da representação Elektra para a representação do formato de armazenamento deve ser feita pelo plugin de armazenamento.

Sim, concordo plenamente. A vantagem da sua abordagem é que ela também permitirá que plug-ins intermediários (entre o tipo e o armazenamento) vejam a representação correta dos booleanos.

Eu atualizei a "Dica de implementação" acima para refletir isso.

@kodebach outra pergunta: JSON só suporta double / boolean / string. É possível dizer ao plugin de tipo que apenas esses 3 tipos são permitidos?

Isso também corrige os tipos JSON mencionados em # 1092.

Isso não seria um problema, pois em JSON a única apresentação disponível é verdadeiro / falso, portanto o usuário não pode escolher.

Eles não podem escolher em JSON, mas podem escolher ao usar kdb set

entre tipo e armazenamento

A ordem deve ser assim: getstorage , type , [outro], type , setstorage , o que significa que nunca deve haver plug-ins entre os tipos e armazenamento.

Eu atualizei a "Dica de implementação" acima para refletir isso.

Ainda existe o problema de que, por exemplo, kdb set user/tests/yajl on não funcionará, sem alterações em type , porque neste caso type passará o valor on para o setstorage plugar.

JSON suporta apenas double / boolean / string. É possível dizer ao plugin de tipo que apenas esses 3 tipos são permitidos?

Não deve ser difícil restringir os tipos permitidos por meio da configuração.

Eles não podem escolher em JSON, mas podem escolher ao usar o conjunto kdb

O que é escolhido em kdb set não pode ser lembrado de qualquer maneira se o formato do arquivo não suportar.

Ainda existe o problema de que, por exemplo, kdb set user / tests / yajl on não funcionará, sem mudanças no tipo, porque neste caso type irá passar o valor para o plugin setstorage.

Por que não se transforma em "1" neste caso?

Não deve ser difícil restringir os tipos permitidos por meio da configuração.

Talvez isso nem importe. Faz diferença se o plug-in de armazenamento ou o plug-in de tipo diz que um tipo não é permitido? Seria bom se o tutorial de armazenamento também dissesse algo sobre os tipos ( @sanssecours ?)

Faz diferença se o plug-in de armazenamento ou o plug-in de tipo diz que um tipo não é permitido?

Não que eu saiba. Provavelmente seria ainda melhor levantar o erro no plugin de armazenamento, porque então o usuário vê que o problema é o uso de yajl não o uso de type .

Por que não se transforma em "1" neste caso?

O procedimento de normalização / restauração pode ser descrito pelos seguintes casos:

• Caso 1: a chave existia em kdbGet e não foi alterada entre kdbGet e kdbSet
  Este é o caso mais fácil e óbvio. O valor é normalizado em kdbGet e o valor original é restaurado em kdbSet , de modo que o arquivo de armazenamento subjacente permanece inalterado (por escrito a chave em questão)
• Caso 2: a chave não existia em kdbGet
  Aqui, normalizamos o valor para verificar o tipo e, em seguida, restauramos imediatamente.
• Caso 3: a chave existia em kdbGet , mas seu valor foi alterado entre kdbGet e kdbSet
  Isso é essencial da mesma forma que o Caso 2. keySetString remove os metadados origvalue , então para o plugin type este tipo de chave não existia em kdbGet .

Existe um caso especial. Já adicionei a funcionalidade que pode ser usada aqui (esqueci de adicioná-la às informações / metadados):

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

Se yajl injetar os metadados check/boolean/true = true e check/boolean/false = false para todas as chaves booleanas, toda a normalização e restauração devem funcionar como pretendido. O plugin type aceitará os valores true , 1 , false e 0 para chaves booleanas (em get e set), mas sempre passará true ou false para o plugin setstorage. O plug-in yajl ainda deve retornar 0 / 1 no get e deve aceitar true / false assim como 0 / 1 em conjunto, para que funcione com ou sem o plugin type .

No entanto, se escolhermos seguir esse caminho, teremos que documentar muito bem, porque montar o plugin de tipo não permitirá mais usar valores diferentes para chaves booleanas em kdb set , porque yajl secretamente substitui qualquer configuração fornecida pelo usuário.

Não que eu saiba. Provavelmente seria ainda melhor levantar o erro no plugin de armazenamento, porque então o usuário vê que o problema é o uso do yajl e não o uso do tipo.

Exatamente.

O procedimento de normalização / restauração pode ser descrito pelos seguintes casos
[...] (esqueci de adicioná-lo às informações / metadados)

Obrigado pela explicação detalhada. Você pode adicionar isso à nossa documentação, por favor?

não permitirá mais usar valores diferentes para chaves booleanas no conjunto kdb

Com "config / needs", yajl pode garantir que o tipo seja montado usando "check / boolean / true = true e check / boolean / false = false".

Portanto, devo alterar a dica de implementação?

Com "config / needs", yajl pode garantir que o tipo seja montado usando "check / boolean / true = true e check / boolean / false = false".

Você entendeu mal, agora check/boolean/true e check/boolean/false devem ser definidos como metadados em uma chave individual, não na configuração de type . O suporte geral dentro da configuração teria que ser adicionado (bastante fácil).

OK. Não, então deixe como está. Faz mais sentido implementar tudo no plugin yajl.
Eu adicionei como dica de implementação:

O plugin yajl precisa:

• [] renderiza os valores "0" e "1" da Elektra para JSON falso e verdadeiro.
• [] falham com erros de tipo se tipos não suportados forem encontrados

@sanssecours você pode adicionar esta informação ao tutorial do plugin de armazenamento?

yajl também tem que adicionar os metadados check/boolean/true = true e check/boolean/false = false a cada chave com type = boolean . Caso contrário, ocorrerá o problema de kdb set /some/key on mencionado acima.

yajl também tem que adicionar os metadados

Isso também é necessário se yajl sempre fornecer apenas "0" e "1" para booleanos?

Sim, porque o problema ocorre, quando o usuário altera o valor da chave após kdbGet . yajl não tem influência nisso.

Mas não se preocupe, precisamos mudar o plugin type qualquer maneira, porque se o usuário adicionar uma nova chave, os metadados não estarão presentes e a solução não funcionará.

Portanto, precisamos que o plugin de tipo esteja disponível duas vezes no caminho kdbSet para que a normalização funcione corretamente? Você pode criar um problema?

Não. Com # 2582 yajl (ou o usuário) só precisa se certificar de que a configuração de type contém

• sem booleans array e boolean/restore = #1
  ou
• tem uma matriz booleans que contém "true" e "false" na posição #X e boolean/restore = #X

Vou tentar consertar isso, mas tenho uma pergunta.

Não deveria ser suficiente definir type=boolean e type/boolean/restoreas=none em uma chave que analiso como booleana em elektraYajlGet ? Então, em elektraYajlSet , devo receber essa chave com o valor 1 ou 0, certo?

Mas ainda estou recebendo o valor fornecido pelo usuário

# 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
É possível que, neste caso, o valor seja sempre restaurado mesmo se type/boolean/restoreas=none ?

/boolean/restoreas não é uma metakey para chaves individuais. É parte da configuração da instância do plugin type usado para o ponto de montagem inteiro.

Acho que deve ser suficiente adicionar config/needs = type/boolean/restoreas=none ao cabeçalho de src/pluigns/yajl/README.md . (Pelo menos para montagem via kdb mount )

Adicionar - infos/config/needs = type/boolean/restoreas=none parece ser um erro do compilador.

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

Posso definir a chave programaticamente também? Não consigo encontrar documentação sobre como configurar outro plugin.

Acho que deveria ser apenas config/need não infos/config/needs . No entanto, não posso verificar agora.

O cabeçalho do README é transformado em linhas de keyNew , que você inclui no método de plug-ins get . Você pode adicionar coisas manualmente lá, usando o README é preferível, uma vez que fornece documentação automaticamente.

Posso definir a chave programaticamente também?

Sim, basta adicioná-lo ao conjunto de chaves do contrato. Por exemplo, a linha a seguir mostra como YAML CPP configura o plug-in type :

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

Obrigado a ambos!

Com o # 3012, o plugin yajl tem o seguinte comportamento.

Com o plugin 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
}

Sem o plugin de tipo

O plugin yajl ainda deve retornar 0 / 1 no get e deve aceitar true / false assim como 0 / 1 em conjunto, para que funcione com ou sem o 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

Isso se refere a quando o plug-in de tipo está montado ou não?

Neste último caso, o comportamento até agora era que fosse emitido um 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

Acho que ainda está bom, pois sem o plugin de tipo, não deveria haver verificação de tipo.

Na verdade, ele deve avisar (ou mesmo falhar) sobre qualquer coisa, exceto "1" ou "0". Além disso, "true", "false" não são booleanos da Elektra.

Imho, o plugin yajl deve ter uma dependência "require" para o plugin type. (mas primeiro também precisamos corrigir o "número", pois não é um dos tipos da Elektra).

Na verdade, ele deve avisar (ou mesmo falhar) sobre qualquer coisa, exceto "1" ou "0". Além disso, "true", "false" não são booleanos da Elektra.

@kodebach escreveu

O plugin yajl ainda deve retornar 0/1 em get e deve aceitar verdadeiro / falso, bem como 0/1 em conjunto, para que funcione com ou sem o plugin de tipo.

Isso é o que eu também permito "verdadeiro" e "falso".

Imho, o plugin yajl deve ter uma dependência "require" para o plugin type. (mas primeiro também precisamos corrigir o "número", pois não é um dos tipos da Elektra).

Sim, concordo totalmente com a dependência. Então, podemos remover o suporte para "verdadeiro" e "falso".

Com relação ao problema do número: Yajl mapeia o tipo de número para o dobro, o que é bom, eu acho. E pela verificação rápida, o tipo duplo do plug-in de tipo também suporta a notação E do json (ou seja, 3.4e2 ).
O que você vê como o problema?

O que você vê como o problema?

Ahh, agora vejo que src / plugins / yajl / testmod_yajl.c 240-251 está comentado. Isso deve ser removido. (Ainda há uma ocorrência de número.)