Как переместить элемент в отсортированный список и сохранить запись CouchDb “атомарной”
У меня есть элементы списка в couchdb документах. Скажем, это 3 элемента в 3 документах:
{ "id" : "783587346", "type" : "aList", "content" : "joey", "sort" : 100.0 }
{ "id" : "358734ff6", "type" : "aList", "content" : "jill", "sort" : 110.0 }
{ "id" : "abf587346", "type" : "aList", "content" : "jack", "sort" : 120.0 }
Представление получает все "aList" документы и отображает их отсортированный по "виду".
Теперь я хочу переместить элементы, когда я хочу переместить "разъем" в середину, я мог сделать это атомарное в одной записи и измениться, это - ключ сортировки к 105,0. Представление теперь возвращает документы в новом порядке сортировки.
После большой сортировки я мог закончить с ключами сортировки как 50,99999 и 50.99998 после того, как несколько лет и в экстремальных ситуациях исчерпывают цифры?
То, что можно рекомендовать, является там лучшим способом сделать это? Я сохранил бы элементы в отдельных документах. Различные пользователи могли бы отредактировать различные элементы списка параллельно.
И пользователи могли бы также изменить порядок документа одновременно (который также может стать хитрым, когда 2 пользователя хотят переместить два различных документа (как joey и jill) в конец со скажем, "видом" = 130.0 одновременно).
Возможно, существует намного лучший путь?
Я пропускал что-то на транзакциях CouchDb?
3 ответа
Вы используете общий шаблон действительного числа для пользовательского управления сортировкой.
Это прекрасная техника, рекомендованная Дэмиеном Кацем. Чтобы перемещаться между соседними документами A и B , установите в поле sort среднее значение A.sort и B.sort .
Этот вопрос состоит из нескольких частей.
А как насчет точности с плавающей запятой?
Javascript Number - это числа с плавающей запятой двойной точности IEEE-754. Они
имеют ограниченную точность.
В парном разряде большая точность. Если это деятельность по инициативе человека, то она пройдет очень много времени, прежде чем перетаскивание достигнет предела. Но у вас есть два варианта:
1.Повторно нормализовать значения сортировки в фоновом режиме
Помните, как переписывали номера строк на BASIC? То же самое.
Сделайте задание cron или другое задание ( NodeJS становится популярным) для проверки недопустимо близких значений сортировки и разделения их. Этот можно использовать сложные эвристики, такие как:
- Подождите, пока сайт не перестанет работать, чтобы исправить
sorts - Подождите, пока конкретный пользователь будет неактивен в течение X времени, прежде чем исправлять его
sorts - Вносите только изменения, которые оставляют
сортировкузначений, но которые никогда не меняются результат просмотра. Другими словами, если у вас есть0,001,0,002и0,003, сначала переместите0,003, например,0,100, затем измените0,002на0,005. Что может иметь небольшой полезный эффект в пользовательском интерфейсе, но помните, что репликация не может скопируйте их в том же порядке, чтобы выгода была минимальной, возможно, не стоит сложность.
2. Используйте десятичный тип данных с неограниченной точностью
Вместо sort , хранящего Javascript Number , он может хранить строку из
, но не включая «0,0» до «1,0» (скажем, до 100 цифр). Тогда строковая сортировка
также числовая сортировка. (У вас есть «якоря» 0,0 и 1,0, которые недопустимы для документов. Чтобы вставить документ в первую позицию, установите sort на среднее значение 0,0 и текущий первый документ.Для последней позиции sort - это среднее значение последнего документа и 1,0.)
Затем вашему клиенту (тому, кто вычисляет значение sort ) необходимо
Типы вещественных чисел произвольной точности. Java, Ruby, Python, почти все
у языков они есть. Этот пост даже вдохновил меня на быстрый проект,
BigDecimal для Javascript , который является BigDecimal
код из Google Web Toolkit (который сам пришел из Apache Harmony). Но есть
есть и другие реализации.
Мне лично нравится BigDecimal . Однако в вашем случае вам придется изменить свой
код для использования строки для sort . Однако преимущество в том, что вам никогда не придется повторно нормализовать
sort для работы с точностью.
А как насчет столкновений из-за одновременной активности?
CouchDB не работает. Произойдет то, чего ожидают пользователи. CouchDB документы имитируют реальный мир. Как говорит Крис Андерсон, «нет транзакции в реальной жизни ».
Для трех элементов пользовательского интерфейса:
- ItemA
- ItemB
- ItemC
Что делать, если я переставлю A после C и вы перемещаете B после C? Ясно, что список будет либо
C B A или C A B . Что это должно быть? Это зависит от вашего приложения?
Либо, это не имеет значения : Отлично! CouchDB будет заказывать A и B произвольно, а вы
будет хорошо. Пользователи сделают вывод (или увидят, в порядке ли ваш пользовательский интерфейс), что кто-то переехал
другой предмет.
Или, B должен стоять перед A, потому что [по какой-то причине] : Итак, ваше значение sort неверно.
Он должен включать все соответствующие данные для определения подвидов. Например, вы можете
emit ([120,000, doc.userLastName], doc) .Когда пользователи перемещают документы в то же место,
сортировка становится алфавитной.
Если вы говорите, A нельзя переместить так скоро после того, как B переместил , то это тоже приложение. код, который необходимо реализовать независимо от хранилища данных. Другими словами, это не транзакционная вещь, это программная логика. Для перетаскивания элементов пользовательского интерфейса Я чувствую, что это того не стоит, и решение «неважно» - лучшее.
Действительно ли текущая система является атомарной? В конце концов, чтобы переместить джек между joey и jill, нам нужно знать значения joey и jill, что требует, чтобы они были запрошены первыми. Вполне возможно, что за время, прошедшее с момента вычисления 105.0, значения joey и jill также изменились. На самом деле, я считаю, что единственным способом, которым это может работать в SQL, была бы блокировка соответствующих строк на время переупорядочения, что привело бы к сериализации запросов на переупорядочение.
Возможно, более подробная информация о проблеме была бы более полезной.
Как насчет добавления 10 к чему-либо> = 110, а затем обновления записи со 130 до 110? Это позволяет сохранять чистые интервалы. Не идеально подходит для записей, которые часто обновляются несколькими пользователями, или для огромных таблиц, но я успешно использую этот метод для небольших и довольно статичных таблиц.