Странный JSON в CouchDB

ProgramBox

Странный JSON в CouchDB

Post author:admin
Запись опубликована:21 апреля, 2023
Post category:Вопросы по программированию

#json #couchdb

Вопрос:

Я изучаю CouchDB I, и мне очень нравится его функциональность. Однако меня беспокоит одна вещь, и это утверждение, что CouchDB обменивается данными через JSON.

На самом деле, JSON требует, чтобы ключами для объектов были строки, в то время как возможно и даже рекомендовано самим Дэмиеном Кацем иметь представления, которые возвращают объекты, ключами которых являются другие объекты или массивы.

Это сбивает с толку, поскольку я нигде не нашел написанного, что CouchDB использует вариант JSON. Более того, это не имеет особого смысла, по крайней мере, по двум причинам:

когда два ключа считаются равными? Например, я предполагаю, что если CouchDB допускает ключи, которые не являются строками, то будут разрешены числа. Но тогда ключи 5 и '5' будут другими, что странно, поскольку в Javascript они считаются одинаковыми.
Что еще более важно, синтаксический анализ выходных данных CouchDB будет более сложным, поскольку нельзя использовать стандартные анализаторы JSON, которые доступны для каждого языка.

Я просто запутался в интерпретации приведенных выше ссылок, или CouchDB действительно возвращает нестандартный вывод JSON? И если да, то как с ним работать?

Ответ №1:

Поле идентификаторов документа ( _id ) должно быть строкой. Ключи просмотра (первый параметр для emit() ) могут быть любым значением JSON. Вы правы, это немного сбивает с толку.

Два ключа считаются равными в соответствии со спецификацией сопоставления CouchDB. В принципе, значения сравниваются так, как и следовало ожидать:

Сортировка чисел по значению
Строки сортируются в соответствии с правилами libicu.
Массивы сортируются путем сравнения первого значения, второго значения и т.д.

Конечно, с идентификаторами документов единственное, что имеет значение, это то, как сортируются строки, поскольку идентификаторы документов всегда являются строками.

Наконец, CouchDB всегда выводит стандартный JSON. Если вы столкнулись с нестандартным JSON из CouchDB, это ошибка, и сообщество хотело бы услышать об этом.

1. Правильно, за исключением одной вещи: параметры сортировки по умолчанию для строк не лексикографические из-за ICU. Так, например, aa < Aa < ab что невозможно для лексикографического упорядочения.

2. Я еще больше запутался. Вы хотите сказать, что CouchDB выводит JSON, содержащий ключи, которые являются, например, массивами , и что CouchDB выводит допустимый JSON?

3. Андреа, CouchDB всегда выводит допустимый JSON. Вы никогда не увидите массив в качестве ключа JSON. Ключи просмотра отличаются, они сами по себе являются полноценными объектами JSON (которые, конечно, хорошо сформированы).

4. Ответ Ананда объясняет мою проблему. Я предположил, что ключи, возвращаемые views, на самом деле были ключами объекта JSON, в то время как объект имеет ключ "key" с ключом view в качестве значения .

Ответ №2:

Не путайте ключи объекта и ключи представления couchdb.

Каждая строка в результате просмотра CouchDB содержит идентификатор, ключ и значение. id является строкой и key и value может быть любым объектом. Очень часто в качестве ключей используются нестроковые значения.

Вот пример результата просмотра с использованием нестроковых ключей.

$ curl http://127.0.0.1:5984/blog/_design/posts/_view/by_date 
{"total_rows":3,"offset":0, "rows":[
{"идентификатор": "88e325c07e897f52766340dc17003322", "ключ": [2010,10,13], "значение": null}, 
{"id": "88e325c07e897f52766340dc17002641", "ключ": [2011,4,5], "значение": null}, 
{"id": "88e325c07e897f52766340dc1700233e", "ключ": [2011,4,23], "значение": null} 
]}

1. Теперь я понимаю: я предположил, что key и value на самом деле были ключами и значениями для объекта JSON, вместо этого они оба являются значениями. Я нахожу это соглашение об именовании вводящим в заблуждение. Что там, чтобы отличить ключ от значения? Можно было бы поместить всю информацию в ключ. Более того, как только ключу и значению присваивается одинаковый статус, emit действительно нет причин выдавать два поля вместо любого числа.

2. Ключу и значению не присваивается одинаковый статус в представлении couchdb. Представление сортируется по ключу, и вы можете связать произвольное значение с каждым ключом. Можно указать функцию уменьшения, которая работает со значениями.

Ответ №3:

Я думаю, это все объясняет.

введите описание изображения здесь

С другой стороны, ключи являются частями операций map / reduce, поэтому мне придется вникнуть в это.

1. Да, вам не разрешено вводить ключи, не являющиеся строками. Но вы получаете их взамен, когда используете map / reduce. Следовало бы упомянуть об этом.

2.Это также может быть ошибкой Futon. Futon автоматически определяет тип вводимых вами данных. Он думает, что вам нужно число 1, которое недопустимо. Однако, используя HTTP напрямую (используя ajax или автономный клиент), вы могли бы получить идентификатор string "1" , без проблем.

3. @jhs: Поля Futon на самом деле являются полями JSON, которые предполагают, что если содержимое не является допустимым JSON, это строковый литерал. Поскольку 1 это допустимый JSON, он сохраняется как таковой. Вы всегда можете записать "1" (это не будет превращено в ""1"" ).

4. 1 недопустим в качестве идентификатора документа CouchDB. Для Futon было бы неплохо использовать "1" , поскольку, по крайней мере, это допустимо. (Некоторые люди могут сказать, не меняйте значение незаметно, с чем я обычно согласен.)