Я могу сделать транзакции и привязываю CouchDB?

Нет. CouchDB использует модель "оптимистичного параллелизма". Простым языком это просто означает отправку версии документа наряду с обновлением, и CouchDB отклоняет изменение, если версия текущего документа не соответствует тому, что Вы отправили.

Это обманчиво просто, действительно. Можно повторно структурировать много нормальных основанных на транзакции сценариев для CouchDB. Действительно необходимо отсортировать, выводят знания проблемной области RDBMS при изучении CouchDB, все же. Полезно приблизиться к проблемам от более высокого уровня, вместо того, чтобы пытаться прессовать Диван к основанному на SQL миру.

Отслеживание материально-технических ресурсов

проблемой, которую Вы обрисовали в общих чертах, является, прежде всего, проблема материально-технических ресурсов. Если у Вас есть документ, описывающий объект, и это включает поле для "количества, доступного", можно обработать проблемы параллелизма как это:

1. Получают документ, принимают во внимание _rev свойство, которое CouchDB отправляет вперед
2. Декремент поле количества, если это больше, чем нуль
3. Передает обновленный документ обратно, с помощью _rev свойство
4. Если _rev соответствия в настоящее время хранившее число, быть сделанным!
5. , Если существует конфликт (когда _rev не соответствует), получите новейшую версию документа

В этом экземпляре, существует два возможных сценария отказа для размышления о. Если новая версия документа имеет количество 0, Вы обрабатываете ее точно так же, как Вы были бы в RDBMS, и предупредите пользователя, что они не могут на самом деле купить то, что они хотели купить. Если новая версия документа имеет количество, больше, чем 0, Вы просто повторяете операцию с обновленными данными и отшатываетесь вначале. Это вынуждает Вас сделать немного больше работы, чем RDBMS был бы и мог получить немного раздражения, если существуют частые, конфликтующие обновления.

Теперь, ответ, который я просто дал, предполагает, что Вы собираетесь сделать вещи в CouchDB почти таким же способом, которым Вы были бы в RDBMS. Я мог бы приблизиться к этой проблеме немного по-другому:

я запустил бы с "основного продукта" документ, который включает все данные дескриптора (имя, изображение, описание, цена, и т.д.). Тогда я добавил бы "документ" билета материально-технических ресурсов для каждого определенного экземпляра с полями для product_key и claimed_by. Если Вы продаете модель молотка и имеете 20 из них для продажи, у Вас могли бы быть документы с ключами как hammer-1, hammer-2, и т.д., для представления каждого доступного молотка.

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

Карта

function(doc) 
{ 
    if (doc.type == 'inventory_ticket' && doc.claimed_by == null ) { 
        emit(doc.product_key, { 'inventory_ticket' :doc.id, '_rev' : doc._rev }); 
    } 
}

Это дает мне список доступных "билетов" ключом продукта. Я мог захватить группу их, когда кто-то хочет купить молоток, затем выполнить итерации посредством отправки обновлений (использующий id и _rev), пока я успешно не буду требовать одного (ранее требуемые билеты приведут к ошибке обновления).

Уменьшают

function (keys, values, combine) {
    return values.length;
}

, Это уменьшает функцию, просто возвращает общее количество невостребованных inventory_ticket объекты, таким образом, можно сказать, сколько "молотков" доступно для покупки.

Протесты

Это решение представляет примерно 3,5 минуты общего количества, думающего для конкретной проблемы, которую Вы представили. Могут быть лучшие способы сделать это! Однако это действительно существенно уменьшает конфликтующие обновления и сокращает потребность ответить на конфликт с новым обновлением. Под этой моделью, у Вас не будет многочисленных пользователей, пытающихся изменить данные в основной записи продукта. В очень худшем, у Вас будут многочисленные пользователи, пытающиеся требовать билета в один конец, и если Вы захватили несколько из тех от Вашего представления, Вы просто идете дальше к следующему билету и попробовали еще раз.

Ссылка: https://wiki.apache.org/couchdb/Frequently_asked_questions#How_do_I_use_transactions_with_CouchDB.3F