MongoDB "Обновить, если текущий" элемента встроенного массива с использованием C # - PullRequest
0 голосов
/ 15 июля 2011

В MongoDB, используя драйвер C #, можно заменить ТОЛЬКО элемент встроенного массива, если он не был изменен с момента его первого извлечения.По сути, это будет «Обновить, если текущий» элемента встроенного массива.

Например, скажем, в STEP # 1 я получаю следующий документ:

{
  "_id": {
    "$oid": "4defe15e2a66bc11986859bb"
  },
  "widgets": [
    {
      "_id": "12312312",
      "views": 3,
      "comments": 7
    },
    {
      "_id": "567567FF",
      "views": 0,
      "comments": 1
    },
    {
      "_id": "890TT890",
      "views": 2,
      "comments": 8
    }
  ],
  "dtcreate": "Wed, 08 Jun 2011 16:53:51 GMT -04:00",
}

Затем в STEP #2 Я извлекаю объект виджета «12312312» и вносю в него некоторые изменения, чтобы обновленный виджет был:

    {
      "_id": "12312312",
      "views": 5,
      "comments": 9
    }

Теперь в ШАГЕ № 3 я использую позиционный оператор для обновления только этого конкретного виджета в документе.

Здесь все работает хорошо, но единственная проблема в том, что я не знаю, произошло ли другое обновление с виджетом "12312312" между STEP # 1 и STEP # 3.

Что яПоиск - это простой способ отменить обновление в ШАГЕ № 3, если какое-либо обновление произошло с виджетом (или даже со всем документом, если это невозможно сделать на уровне виджета) между # 1 и # 3.

Ответы [ 2 ]

0 голосов
/ 15 июля 2011

Этот же вопрос был размещен здесь:

http://groups.google.com/group/mongodb-user/browse_thread/thread/888f5e14145d9f0c#

Обычно это лучше всего работает, когда обсуждение объединено в одном месте.

0 голосов
/ 15 июля 2011

Лучший способ избежать одновременных обновлений:

  1. Обновление мелких деталей (не весь виджет, если это не требуется).
  2. Обновите некоторую часть документа из одного места кода с помощью lock, чтобы убедиться, что несколько потоков не обновляют одновременно одну и ту же часть документа (это наверняка будет узким местом).
  3. Создайте базу данных таким образом, чтобы избежать одновременного обновления одних и тех же частей документа.

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

Но, например, RavenDB поддерживает транзакции, но транзакции (в частности, между несколькими серверами) обычно убивают масштабируемость. Цель Mongodb - масштабируемость и прощай ACID и транзакций.

Окончательная согласованность в mongodb:

MongoDB полагается на возможную последовательность, а не строгую последовательность. Тот означает, что когда происходит запись и возвращается команда записи, мы не можем быть на 100% уверенным, что с этого момента все остальные процессы увидит только обновленные данные. Они только в конечном итоге смогут увидеть изменения. Это влияет на кэширование, потому что мы не можем сделать недействительными и немедленно заполняйте наши кэши, но опять же, в веб-приложениях часто не имеет большого значения, если для распространения обновления требуется несколько секунд

Так что, если вы не начали разработку с mongodb, вы можете просмотреть другие базы данных.

Просто убедитесь, что вы используете правильный инструмент для своих задач.

Надеюсь, это поможет.

...