Ограничения на уникальность данных в couchdb

Question

Ограничения на уникальность данных в couchdb

Каждый раз, когда Ваша функция возвращает IEnumerable, необходимо использовать "получение". Не в.Net> 3.0 только.

пример.Net 2.0:

  public static class FuncUtils
  {
      public delegate T Func<T>();
      public delegate T Func<A0, T>(A0 arg0);
      public delegate T Func<A0, A1, T>(A0 arg0, A1 arg1);
      ... 

      public static IEnumerable<T> Filter<T>(IEnumerable<T> e, Func<T, bool> filterFunc)
      {
          foreach (T el in e)
              if (filterFunc(el)) 
                  yield return el;
      }


      public static IEnumerable<R> Map<T, R>(IEnumerable<T> e, Func<T, R> mapFunc)
      {
          foreach (T el in e) 
              yield return mapFunc(el);
      }
        ...

27

couchdb

задан Barry Wark 9 October 2009 в 00:20

2 ответа

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

Если вас интересует только случай с одним сервером. возможно, вы могли бы перестроить свои couchjs с поддержкой сети и выполнить HTTP-запрос в своей функции validate_doc_update () , которая будет выполнять запрос к БД, чтобы узнать, используется ли уже адрес электронной почты, и не выполнить обновление, если так. См. здесь для получения дополнительных сведений о механизме проверки. Я не рекомендую это делать,

9

ответ дан 28 November 2019 в 05:12

Другие вопросы по тегам:

couchdb

Похожие вопросы:

score 14 · Accepted Answer

Это одна из менее интересных частей CouchDB. Лучший способ, который я нашел для обработки уникальных полей, которые могут изменяться (как в вашем пользовательском примере), - это создать «указатель» документы с уникальными значениями в качестве компонента ключа, а затем использовать их, чтобы вы могли требовать уникальные значения. Важной частью этого является наличие предсказуемого ключа для первичного документа с последующим сохранением документов заявки на уникальное поле до сохранения первичного (и разрешение конфликтов ключей препятствовать сохранению первичного документа).

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

user-1234: { username: "kurt", email: "kurt@localhost" }
user-9876: { username: "petunia", email: "pie@crust.com" }

Уникальные указатели полей будут выглядеть примерно так:

user-username-kurt: { primary_doc: "user-1234" }
user-email-kurt@localhost: { primary_doc: "user-1234" }
user-username-petunia: { primary_doc: "user-9876" }
user-email-pie@crust.com: { primary_doc: "user-9876" }

Создание или обновление пользователя потребует следующих шагов:

Подготовьте пользовательский документ, сгенерируйте ключ для этого, если необходимо
Сохраните документ-указатель для каждого измененного уникального поля
Если сохранение любого из них не удается, остановите и исправьте ошибки
Сохраните основной пользовательский документ

Шаг 3 потребует некоторых размышлений. Например, вы выиграли ' Я не хочу попробовать требовать уникальные значения для полей, которые не изменились. Вы могли бы, но тогда вам придется добавить некоторую дополнительную логику, чтобы обработать случай, когда вы заявляете значение для пользователя, который уже владеет этим значением.

Шаг 3 был бы хорошим местом, чтобы позволить людям взять старую заявленные значения. Если, например, один пользователь «выпустил» имя пользователя kurt, я могу просто обновить этот конкретный документ, чтобы он указывал на мой новый ключ, после проверки того, что он больше не используется. Альтернативой является удаление заявленных уникальных значений при их изменении. Я не уверен, что было бы меньше работы на самом деле. Для меня наиболее разумно оставить устаревшие заявленные значения.

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

Эта настройка также позволяет вам устанавливать отношения, не беспокоясь о каскадировании пользовательских ключей. Не знаю, как вы, но на мои пользовательские документы ссылаются почти все другие документы в системе. Изменение пользовательского ключа было бы огромной головной болью.