Работа с схемой JSON в CouchDB

Question

Я бы спросил о хороших практиках относительно схем JSON в CouchDB. В настоящий момент я использую чистый CouchDB 1.6.1. Я справляюсь с этим без какой-либо платформы couchapp (я знаю, что это полезно, но я обеспокоен тем, что он будет функционален в будущем).

• Где находится схема в CouchDB? Как обычный документ? Проектный документ? Или, может быть, сохранить их как файл? Но если бы я их проверял, особенно на стороне сервера в функции validate_doc_update, они должны храниться в проектных документах.

• Есть ли какая-либо библиотека (JavaScript будет лучше) с работами в CouchDB и Client (веб-браузер)? Библиотека с я мог бы генерировать JSON и проверять их автоматически?

• Я думаю о том, как отправлять данные клиенту, хранить их во входных тегах, а затем собирать как-то и отправлять в serwer. Может быть установлен входной идентификатор в качестве пути к полю, в примере:

  { "Adress": { "Street": "ххх", "Nr": "33" } }

В этом случае вход может иметь id = «Адрес». «Улица», но я не знаю, это хорошее решение. Я должен отправить схему с сервера и построить объект JSON с использованием этой схемы, но не знаю, как (в случае, если все поля в JSON были уникальные имена, включая иерархии).

Answer 1

Вы задаете тот же вопрос, который у меня был в течение многих лет, изучая потенциальные преимущества CouchDB в прецедентах использования форм-данных.

Первоначально я надеялся найти подход, который позволяет проверять данные на основе того же кода определения и кода проверки JSON - сервера и клиента. Оказалось, что это не только возможно, но и некоторые дополнительные преимущества.

Где размещена схема в CouchDB? Как обычный документ? Проектный документ? Или, может быть, сохранить их как файл? Но если бы я их проверял, особенно на стороне сервера в функции validate_doc_update, они должны храниться в проектных документах.

Вы правы. Проект doc (ddoc), который также включает функцию validate_doc_update для выполнения проверки перед обновлением doc, является наиболее распространенным местом для размещения этих схем. this в функции validate_doc_update является самим ddoc - все, что входит в ddoc, можно получить из код проверки.

Я начал хранить схемы как объект JSON в своей общей библиотеке/папке для модулей commonjs, например. lib/schemata.json. Свойство type моих документов указало ключ схемы, который должна получить подтверждение проверки документа. type: 'adr' ->lib/schemata/adr.Схема может также ссылаться на другие схемы на каждое свойство - рекурсивная функция проверки прошла до конца любого свойства независимо от того, какой тип вложенных свойств был. Он хорошо зарекомендовал себя в первом проекте.

{ 
    "person": { 
    "name": "/type/name", 
    "adr": "/type/adr", 
    ... 
    }, 
    "name": { 
    "forname": { 
     "minlenght": 2, 
     "maxlength": 42, 
     ... 
    }, 
    "surname": { 
     ... 
    } 
    }, 
    "adr": { 
    ... 
    } 
} 

Но тогда я хотел использовать подмножество этих схем в другом проекте. Чтобы просто скопировать его и добавить/удалить некоторые схемы, было бы слишком недальновидным мышлением. Что делать, если общая схема для адреса имеет ошибку и нуждается в обновлении в каждом проекте, который используется?

В этот момент мои схемы были сохранены в одном файле в репозитории (я использую в качестве инструмента для загрузки для ddocs). Затем я понял, что когда я храню каждую схему в отдельном файле, например. adr.json, geo.json, tel.json и т. Д. Это приводит к тому же JSON-структуре на серверах ddoc, как и раньше, с использованием единого файлового подхода. Но он был более подходящим для управления исходным кодом. Мало того, что файлы меньшего размера приводят к меньшим конфликтам слияния и более чистой истории фиксации, также было включено управление зависимостями схемы через субрепозитории (подмодули).

Другая мысль заключалась в том, чтобы использовать CouchDB как место хранения и управления схемами. Но, как вы уже упоминали об этом, схемы должны быть доступны в функции validate_doc_update. Сначала я попробовал подход с обработчиком обновления - все обновления документа должно пройти обработчик обновления проверки, который извлекает правильную схему из CouchDB сам по себе:

POST /_design/validator/_update/doctype/person 

function (schema, req) { 
    ... //validate req.body against schema "person" 
    return [req.body, {code: 202, headers: ...}] 
} 

Но этот подход не очень хорошо работает с вложенными схемами. Хуже того - для предотвращения обновлений doc без проверки через обработчик мне пришлось использовать прокси перед CouchDB, чтобы скрыть прямые встроенные пути обновления док-станции (например, POST to/the/doc/_id). Я не нашел способ обнаружить в функции validate_doc_update, был ли обработчик обновления задействован до или нет (может быть, у кого-то есть? Я был бы рад прочитать такое решение.).

Во время этого исследования на моем радаре появляется проблема с разными версиями той же схемы. Как мне это сделать? Должны ли все документы из того же типа быть действительными в отношении одной и той же версии схемы (что означает необходимость переноса данных в формате db перед почти каждой версией схемы)? Если свойство type также содержит номер версии? и т.д.

Но подождите! Что делать, если схема документа прикреплена к самому документу? Он:

• обеспечит совместимую версию к содержанию DOC в документ
• быть доступны в функции validate_doc_update (в oldDoc)
• могут быть воспроизведены без права доступа администратора (как вам нужно для DDoc обновления)
• будут включены в каждом ответе на запрос док стороне клиента

Это звучало очень интересно, и до сих пор мне кажется, что это самый подход CouchDB-ish. Сказать это ясно - Схема документа прикреплена к самому документу - означает хранить его в собственности документа. Как хранилище в виде вложения, так и использование самой схемы в качестве структуры документа были неудачными.

Наиболее чувствительным моментом такого подхода является C (создать) в жизненном круге CRUD документа.Существует множество различных решений, которые можно представить, чтобы убедиться, что присоединенная схема «правильная и приемлемая». Но это зависит от вашего определения этих условий в вашем конкретном проекте.

Есть ли какая-либо библиотека (JavaScript будет лучше) с работами в CouchDB и Client (веб-браузер)? Библиотека с я мог бы генерировать JSON и проверять их автоматически?

Я начал применять с популярным JQuery Validation plugin. Я мог бы использовать схему как конфигурацию и автоматически проверять на стороне клиента. На стороне сервера я извлек функции проверки как модуль commonjs. Я ожидал, что позже найду модульный способ управления кодом, который предотвратит дублирование кода.

Оказалось, что большинство существующих фреймворков валидации очень хороши в сопоставлении шаблонов и валидации единственного свойства, но не способны проверять соответствие значений зависимостей в одном документе. Также требования к определению схемы часто слишком проприетарны. Для меня правильное правило для выбора правильного определения схемы: предпочитайте стандартизованное определение (jsonschema.org, microdata, rdfa, hcard и т. Д.) Над собственной реализацией. Если вы оставите структуру и имена свойств как они есть, вам потребуется меньше документации, меньше трансформации, а иногда вы получите совместимость с зарубежным программным обеспечением, которое ваши пользователи используют также (например, календари, адресные книги и т. Д.) Автоматически. Если вы хотите реализовать HTML-презентацию для своих документов, вы хорошо подготовлены к ее выполнению в семантическом веб-и-SEO-виде.

И, наконец, - не желая звучать высокомерно - написать реализацию проверки схемы не составит труда. Возможно, вы хотите прочитать исходный код плагина проверки JQuery - я уверен, что вы находите это, как я, удивительным. Во времена, когда скорость оттока интерфейсных фреймворков увеличивается, возможно, это самый надежный способ обеспечения собственной проверки. Кроме того, я считаю, что вы должны иметь 100% понимание реализации валидации - это критическая часть вашего приложения. И если вы понимаете иностранную реализацию - вы также можете написать библиотеку самостоятельно.

ОК. Это легкий ответ. Сожалею. Если кто-то читает это до конца и хочет увидеть его подробным в действии с примером исходного кода - upvote, и я напишу сообщение в блоге и добавлю URI в качестве комментария.

Answer 2

Возможно, лучшим вариантом является u se json-schema. У вас есть реализации в a lot of languages. Я успешно использовал tv4 в javascript.

Для того, чтобы интегрироваться с db-кушеткой, я считаю, что лучшим вариантом является определение validation function и использование javascript-проверки json-schema.

Answer 3

Я расскажу вам, как я его реализую.

1. У меня есть база данных по типу документа, которая позволяет мне реализовать одну схему для каждой базы данных.

2. В каждой базе данных у меня есть _design/schema ddoc, который содержит схему и функцию validate_doc_update для ее проверки.

3. Я использую Tiny Validator (for v4 JSON Schema), который я включаю прямо в _design/schema ddoc.

---

_design/schema DDoc выглядит следующим образом:

{ 
    "_id": "_design/schema", 
    "libs": { 
    "tv4": // Code from https://raw.githubusercontent.com/geraintluff/tv4/master/tv4.min.js 
    }, 
    "validate_doc_update": "..." 
    "schema": { 
    "title": "Blog", 
    "description": "A document containing a single blog post.", 
    "type": "object", 
    "required": ["title", "body"], 
    "properties": { 
     "_id": { 
     "type": "string" 
     }, 
     "_rev": { 
     "type": "string" 
     }, 
     "title": { 
     "type": "string" 
     }, 
     "body": { 
     "type": "string" 
     } 
    } 
    } 
} 

---

validate_doc_update функция выглядит следующим образом:

function(newDoc) { 
    if (newDoc['_deleted']) return; 

    var tv4 = require('libs/tv4'); 

    if (!tv4.validate(newDoc, this.schema)) { 
    throw({forbidden: tv4.error.message + ' -> ' + tv4.error.dataPath}); 
    } 
} 

Надеется, что это помогает.