Terima kasih telah melaporkan masalah tersebut!

Seperti apa dokumen JSON itu? Kami juga memerlukan dokumentasi untuk semantik khusus dari file konfigurasi yang hanya berisi kunci induk.

Seperti apa dokumen JSON itu?

Dalam kasus ini, dokumen hanya akan berisi string:

"This May Be the Year I Disappear"

. Plugin sudah membaca nilai yang benar, jika saya mengganti file konfigurasi dengan konten di atas:

printf '"This May Be the Year I Disappear"' > (kdb file user/tests/yajl/)
kdb get user/tests/yajl
#> This May Be the Year I Disappear

.

Jadi hanya set yang perlu diperbaiki? Kedengarannya cukup mudah!

Jadi hanya set yang perlu diperbaiki?

Sejauh yang saya tahu, ya.

Saya rasa saya bisa melihat ini sebagai edisi pertama saya. Dapatkah Anda memberi saya beberapa petunjuk di mana saya harus mulai mencari @ markus2330? Terima kasih.

Sumbernya ada di src / plugins / yajl / yajl_gen.c dan src / plugins / yajl / yajl_parse.c

Untungnya @sanssecours menulis tutorial yang sangat bagus yang menjelaskan bagaimana seharusnya plugin penyimpanan berperilaku (lihat doc / tutorials / storage-plugins.md). Jadi Anda dapat mengambil sebagai masalah berikutnya # 2132 (# 2477 mungkin akibat dari ini) dan masalah terkait yajl lainnya. Pekerjaan utama Anda adalah validasi array di plugin yajl atau - bahkan lebih baik - sebagai plugin eksternal (lihat # 1862).

Jika saya memasang dokumen json kosong (artinya hanya berisi {} ), maka hal berikut terjadi ketika saya memanggil kdb set system/lvas/cm/yajl "test" .
elektraYajlSet dipanggil dengan KeySet yang memiliki jus (system/lvas/cm/yajl,test) sebagai nilainya.

Dalam panggilan ke elektraGenEmpty klausa kedua dijalankan, karena ukuran KeySets adalah 1.
Strcmp juga berhasil karena parentKey memiliki nilai yang sama dengan kunci terakhir di Keyset.

Peta kosong dihasilkan dan elektraYajlSet berakhir. Jadi fungsi tersebut menerima nilai, tetapi tidak melakukan apa pun dengannya.

Jadi pada titik di mana peta kosong dibuat, saya dapat menambahkan kode yang mengeluarkan nilai kunci ke dalam dokumen json seperti yang dijelaskan oleh @sanssecours di sini .
Ini akan berhasil, karena kdb membaca nilai itu dengan benar dan panggilan seperti kdb set system/lvas/cm/yajl/second "hi" menghasilkan dokumen json seperti ini {"__dirdata": "test", "second": "hi"} , yang memetakan kunci seperti yang diharapkan.

Saya pikir solusi ini akan berfungsi, tetapi saya akan merasa lebih bersih jika saya dapat mengatur dokumen json langsung ke {"__dirdata": "test"} , yang akan sama secara semantik.

Tetapi saya tidak yakin bagaimana saya akan melakukannya. Saya berasumsi bahwa cara yang benar adalah bahwa plugin directoryvalue akan mengubah Keyset yang diterima elektraYajlSet. Atau saya kira saya bisa memodifikasi KeySet sendiri di elektraYajlSet.

Apakah Anda punya saran @ markus2330?

Ya, nilai direktori mengubah KeySet yang diterima elektraYajlSet. Ini tidak terjadi, namun, jika hanya parentKey yang ada (karena tidak dianggap sebagai "direktori" maka.) Jadi jika Anda hanya mengatur kunci induk, seperti yang sudah Anda ketahui, elektraGenEmpty akan dijalankan dan strcmp berhasil.

Tetapi elektraGenEmpty memiliki beberapa asumsi yang sekarang tidak benar lagi (ditulis sebelum nilai direktori ada). Jadi ada bug lain, misalnya # 2132

Saya pikir solusi ini akan berhasil, tetapi saya akan merasa lebih bersih jika saya dapat menyetel dokumen json langsung ke {"__dirdata": "test"}, yang secara semantik akan sama.

Bukankah {"": "test"} merupakan dokumen minimal yang menjelaskan satu nilai? Ini juga tampaknya merupakan perilaku plugin "unta".

@sanssecours Bisakah Anda memperluas penyimpanan-tutorial untuk juga menjelaskan parentKeys dan "kunci kosong" (%) (atau setidaknya sebagai TODO untuk saat ini)?

Bisakah Anda memperluas penyimpanan-tutorial untuk juga mendeskripsikan parentKeys…

Saya pikir tutorial plugin sudah menjelaskan

• nilai kunci orang tua (jalur file), dan
• bahwa kunci induk digunakan untuk mengeluarkan kesalahan dan informasi peringatan

. Saya tidak tahu hal lain yang spesial tentang kunci orang tua.

dan "kunci kosong" (%) (atau setidaknya sebagai TODO untuk saat ini)?

Karena ini pertama kalinya saya mendengar tentang kunci kosong, saya rasa saya bukan orang yang tepat untuk melakukannya.

Saya dapat menambahkan kode yang mengeluarkan nilai kunci ke dalam dokumen json seperti yang dijelaskan oleh @sanssecours di sini .

Saya tidak yakin apakah ini cara yang benar bagi YAJL untuk menangani masalah ini lagi, karena dokumen JSON yang valid tampaknya selalu memerlukan larik atau objek di tingkat atas.

Saya tidak tahu hal lain yang spesial tentang kunci orang tua.

Juga tidak ada yang istimewa tentang itu kecuali bahwa beberapa format file konfigurasi tidak memiliki cara untuk menggambarkan nilai tanpa kunci.

"kunci kosong" (%)

Kunci kosong memungkinkan Anda memetakan dokumen seperti {"root": {"": "something"}} . Bagaimana Anda memetakan ini saat ini ke KeySet?

Saya tidak yakin apakah ini cara yang benar bagi YAJL untuk menangani masalah ini lagi, karena dokumen JSON yang valid tampaknya selalu memerlukan larik atau objek di tingkat atas.

Ini sepertinya telah berubah: https://stackoverflow.com/questions/13318420/is-a-single-string-value-considered-valid-json

Di https://www.ietf.org/rfc/rfc7159.txt bahkan ada contoh yang menunjukkan bahwa "hanya nilai" yang diperbolehkan. Tapi sepertinya yajl tidak mendukung ini ... (yajl 2.1.0-2 + ​​b3 menghasilkan kesalahan Expected “{” but found “"” )

Dengan fitur dari RFC 7159 kita bisa memetakan:

"some value" -> parent = "beberapa nilai"
{"", "some value"} -> induk /% = "beberapa nilai"

Tapi kita perlu mengatasi yajl lalu ... (ChangeLog juga tidak menunjukkan bahwa fitur ini ditambahkan nanti).

Kunci kosong memungkinkan Anda memetakan dokumen seperti {"root": {"": "something"}}. Bagaimana Anda memetakan ini saat ini ke KeySet?

Sepertinya YAML CPP menangani data ini dengan benar:

kdb mount config.yaml user/tests/yaml yamlcpp
printf '{"root": {"": "something"}}' > "$(kdb file user/tests/yaml)"
kdb ls user/tests/yaml
#> user/tests/yaml/root/%
kdb get user/tests/yaml/root/%
#> something

. Saya tidak mengadaptasi plugin untuk kunci kosong. Hanya memanggil setBaseName di plugin penyimpanan, menggunakan nilai string yang benar ( "" ), sudah cukup untuk mendukung fitur ini.

Senang melihat bahwa ini berfungsi di luar kotak tanpa penanganan khusus: +1:

@sanssecours Apakah sekarang kita ingin mendukung RFC 7159? Apa yang plugin Anda lakukan jika hanya parentKey yang disetel?

Apakah sekarang kami ingin mendukung RFC 7159?

Menurut pendapat saya, mendukung setiap tipe data di tingkat atas masuk akal.

Apa yang plugin Anda lakukan jika hanya parentKey yang disetel?

Mereka hanya menyimpan teks (tanpa kunci):

kdb mount config.yaml user/tests/yaml yamlcpp
kdb set user/tests/yaml value
kdb file user/tests/yaml | xargs cat
#> value

.

Saya menambahkan penanganan khusus untuk level teratas dalam komit ini .
Itu merusak tes dalam modul yajl, tetapi sebelum saya pergi dan menghabiskan waktu untuk memperbaikinya, saya ingin check-in dulu, apakah itu solusi yang dapat diterima @ markus2330?

Sekadar menjelaskan sedikit: Jika ukuran KeySet adalah 1, maka saya dapat yakin bahwa hanya kunci tingkat atas yang ada di dalamnya. Kemudian saya menghasilkan nilai kunci itu. Tetapi dalam kasus itu saya harus mencegah elektraGenOpenValue dipanggil, karena itu akan menghasilkan kunci sebagai string.

Sepertinya YAML CPP menangani data ini dengan benar:
...

Contoh ini cocok untuk saya dengan yajl. Apakah saya melewatkan sesuatu?

Itu mematahkan ujian dalam modul yajl

Tes yang mana? (lihat juga di bawah)

Saya ingin check-in dulu, apakah itu solusi yang dapat diterima

Lebih mudah untuk melihat apakah ada solusi yang dapat diterima jika:

• Anda membuat PR (yang kemudian akan menjalankan semua kasus uji)
• jelaskan dalam tes dan dengan contoh perilaku mana yang sekarang ingin Anda terapkan

Contoh ini cocok untuk saya dengan yajl. Apakah saya melewatkan sesuatu?

Tidak, contoh ini hanya menunjukkan bahwa {"", "some value"} bukanlah cara yang ideal untuk merepresentasikan nilai parentKey.

Apakah sekarang kami ingin mendukung RFC 7159?
Menurut pendapat saya, mendukung setiap tipe data di tingkat atas masuk akal.

Saya sangat setuju.

Mereka hanya menyimpan teks (tanpa kunci):

Jadi mari kita terapkan hal yang sama dengan yajl.

Ini bekerja dengan sempurna untuk saya sekarang!