Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
Одно Derby приложение состоит из одного серверного приложения (Express) и одного или нескольких клиентских.А где-нибудь есть пример одного серверного и нескольких клиентских?
Derby.js работает только с Redis, за которым может быть любая БД. В официальной документации описан только Redis+MongoDB.
Есть возможность написать адаптер для mysql, если так хочется. Это будет не трудно.
А есть ли подобные в общем доступе? А то для LiveDB я не нашёл адаптеров под mysql :(
Нету. Напишите, выложите, будет в доступе.
Вот как выглядит адаптер для mongo. Но мой взгляд не сложно.
Вот как выглядит адаптер для mongo. Но мой взгляд не сложно.
Мне кажется, для mysql все может быть несколько сложнее, все-таки монго штука безсхемная.
Есть ли адаптер для Redis? Зачем авторы используют 2 хранилища? Если Redis обязателен, то почему бы не использовать только его?
Потому-что Redis — это In-memory бд. Все данные лежат в оперативной памяти и их размер ограничен как вы понимате. Конечно вы можете купить много памяти, но это всегда ограниченно. Для каких-то проектов это возможно. Я согласен.
Вторая проблема — это то что Redis с настройками по умолчанию сохраняет данные на диск периодически. То есть большую часть времени данные не синхронизированны и при неполадках потеряются. Можно поменять настройки (чтобы записывалось на диск после каждой операции), но тогда скорость работы Redis сильно упадет и по сути сведет на нет все его достоинства.
Адаптера для Redis нету. Зато есть адаптер для mongo.
Redis используется для Pub-sub и кэша операций. Данные хранятся в mongo.
Вторая проблема — это то что Redis с настройками по умолчанию сохраняет данные на диск периодически. То есть большую часть времени данные не синхронизированны и при неполадках потеряются. Можно поменять настройки (чтобы записывалось на диск после каждой операции), но тогда скорость работы Redis сильно упадет и по сути сведет на нет все его достоинства.
Адаптера для Redis нету. Зато есть адаптер для mongo.
Redis используется для Pub-sub и кэша операций. Данные хранятся в mongo.
Ясно, спасибо.
В этом случае можно было бы, например, использовать JugglingDB или написать адаптер для этой ORM. Это позволит в т.ч. и «реляционщикам» угодить, да и вообще ;)
В этом случае можно было бы, например, использовать JugglingDB или написать адаптер для этой ORM. Это позволит в т.ч. и «реляционщикам» угодить, да и вообще ;)
Можно поменять настройки (чтобы записывалось на диск после каждой операции), но тогда скорость работы Redis сильно упадет и по сути сведет на нет все его достоинства.
Это не так. Почитайте про fsync и вообще как устроена работа с диском в линуксах. Если не форсить врайт в дисковый кеш, то скорость будет «хорошей», а данные зафакапятся в случае фейла ОС, а не редиса.
Спасибо за уточнение.
Я конечно почитаю, но вы можете подробнее расписать? Как будет при RDB, как при AOF? Какая скорость, какая надежность? Я думаю многим будет интересно и полезно. Если есть какие-то тесты, вообще будет здорово. Тут даже пост можно написать.
Я конечно почитаю, но вы можете подробнее расписать? Как будет при RDB, как при AOF? Какая скорость, какая надежность? Я думаю многим будет интересно и полезно. Если есть какие-то тесты, вообще будет здорово. Тут даже пост можно написать.
Сразу же нагуглил этот топик — redis.io/topics/persistence
Но, да, поддерживаю, с теcтами было бы веселее, особенно в сравнении с mongo.
Но, да, поддерживаю, с теcтами было бы веселее, особенно в сравнении с mongo.
Простите, я не хочу этого делать, кроме того не считаю себя достаточно компетентным :)
Я просто уточнил, что вообще то писать транзакционный лог это нормально и потеря производительности здесь если и есть, то не столько критична, как у вас написано, зависит от типа синка. В общем все как и с другими БД.
Я просто уточнил, что вообще то писать транзакционный лог это нормально и потеря производительности здесь если и есть, то не столько критична, как у вас написано, зависит от типа синка. В общем все как и с другими БД.
Сам использую Derby для разных целей. Есть большой проект crm-erp системы. Есть мелкие сайты, где даже нету базы данных, а есть только статичные страницы, генерирующиеся на сервере. Везде это крайне удобно и в тему.
Derby — очень гибкая штука. Если пойдете на слона, то можете из нее собрать пушку, А если на воробья — то рогатку.
Derby — очень гибкая штука. Если пойдете на слона, то можете из нее собрать пушку, А если на воробья — то рогатку.
Есть ли опыт «под нагрузкой»? Как себя ведет?
Какие бы вы рекомендации дали?
Что однозначно «стоит» делать, а что «не стоит»?
Какие бы вы рекомендации дали?
Что однозначно «стоит» делать, а что «не стоит»?
К сожалению опыта «под нагрузкой» как такового нету. Мой проект — интранет для одной компании.
Создатели Derby сейчас пилят проект Lever. И где-то писали, что сейчас слабое место (в плане произодительности) не синхронизация данных, а шаблонизатор. По этому в данный момент шаблонизатор переписывается и выйдет в версии 0.6. Это будет не раньше, чем через пару месяцев.
Создатели Derby сейчас пилят проект Lever. И где-то писали, что сейчас слабое место (в плане произодительности) не синхронизация данных, а шаблонизатор. По этому в данный момент шаблонизатор переписывается и выйдет в версии 0.6. Это будет не раньше, чем через пару месяцев.
CRM-ERP на монго, мне очень интересно на это посмотреть. Я с трудом, но могу представить CRM на NoSQL но вот ERP уже не могу. Не могли бы написать хотя бы поверхностную статью по архитектуре.
Спасибо за статью, по Derby.js ощущается острейшая нехватка обучающих материалов.
Но к сожалению, это не туториал, а что-то вроде FAQ.
Но к сожалению, это не туториал, а что-то вроде FAQ.
Спасибо за отзыв. Рад если помогло.
Давайте идею для туториала тогда. Про что написать? Что не понятно? Примеры какие нужны?
Давайте идею для туториала тогда. Про что написать? Что не понятно? Примеры какие нужны?
Рад если помогло.
Не помогло. Дело вот в чем.
Я верстальщик, хорошо знаю HTML и CSS (SASS), с Linux — на вежливое «ты». Я достаточно освоил клиентский JS и немного Ruby, чтобы задуматься о том, чтобы слезть с пресловутого Drupal. Встал вопрос о выборе фреймворка для изучения.
С моим текущим уровнем подготовки мне хватит способностей, чтобы освоить, например, AngularJS + Rails/Padrino. Но у DerbyJS порог вхождения настолько чудовищно высок, что я теряюсь, даже не начав. Node/Express для меня — темный лес. С серверным JS я не работал никогда. Redis в глаза не видел. Настройка окружения Bower и Grunt (и подцепление Ruby'шных SASS и Compass, без которых я не могу) представляется мне сложнее, чем написание самого приложения. И это я еще не говорю о смене парадигмы программирования.
Звучит достаточно жалко, да. Но поймите, что среди читающих вашу статью людей, которые способны сходу взять этот материал на вооружение, — единицы, а таких растерянных как я — большинство.
Поэтому имеет место огромная потребность в обучающих материалах, начиная с самых азов: настройка окружения Node/Grunt/Bower/Redis/MongoDB, азы Node, азы Express, первые шаги на Derby, азы Redis и MongoDB, азы Heroku (благо, как я недавно узнал, у них есть беслптный тариф)… Всё разжевывать и скармливать по ложечке. В противном случае получается как в том анекдоте. :(
Так что на вас вся надежда. В рунете людей, хорошо знающих Derby, совсем немного, а готовых прикладывать усилия для его популяризации — единицы. Но самое смешное и печальное то, что даже на английском языке обучающих материалов по Derby — чудь более, чем нифига.
Но самое смешное и печальное то, что даже на английском языке обучающих материалов по Derby — чудь более, чем нифига.Блин, полностью с вами согласен. Даже туториала ни одного нормального, есть один жалкий, но он по сути позволяет разобраться лишь с тем, как дерби установить и создать (автогенерируемую) болванку для приложения без всяких пояснений работы… :(
Спасибо за добрые слова. Особенно мне понравилась фраза про «вся надежда только на меня». :-)
Вряд ли имеет смысл писать туториалы по Redis или Mongo DB. Думаю их и так достаточно.
Тем более на первом этапе не нужно про них почти ничего знать.
Node и Express можно тоже в принципе освоить походу. Хотя какую-нибудь книжку по Node прочитать не было бы лишним (ибо не похож на другие платформы).
Grunt я не использую. Derby автоматом обновляет html, css на клиенте при изменении. А для coffeescipt`а (пишу на нем) я использую:
Что такое Bower я узнал только сейчас. Но так и не понимаю зачем он нужен если есть browserify и npm-пакеты на клиенте. Может вы мне объясните?
Итого есть две идеи для туториалов:
1) С нуля с настраиванием окружения и прочее до hello world.
2) Написать какое-то приложение шаг по шагу. Что это может быть? интернет магазин? crm-система? социальная сеть? только давайте не супер сложное что-то.
Что еще могу для вас сделать?
Вряд ли имеет смысл писать туториалы по Redis или Mongo DB. Думаю их и так достаточно.
Тем более на первом этапе не нужно про них почти ничего знать.
Node и Express можно тоже в принципе освоить походу. Хотя какую-нибудь книжку по Node прочитать не было бы лишним (ибо не похож на другие платформы).
Grunt я не использую. Derby автоматом обновляет html, css на клиенте при изменении. А для coffeescipt`а (пишу на нем) я использую:
coffee -w
Что такое Bower я узнал только сейчас. Но так и не понимаю зачем он нужен если есть browserify и npm-пакеты на клиенте. Может вы мне объясните?
Итого есть две идеи для туториалов:
1) С нуля с настраиванием окружения и прочее до hello world.
2) Написать какое-то приложение шаг по шагу. Что это может быть? интернет магазин? crm-система? социальная сеть? только давайте не супер сложное что-то.
Что еще могу для вас сделать?
Фишка Bower — в вытягивании библиотек прямо с GitHub'а. Если вам нужна JS-приблуда, доступная на GitHub и отсутствующая в npm, вы можете написать конфиг для Bower, и он будет ее вытягивать для вас (и ваших коллег) автоматом, при этом добавлять исходник библиотеки в систему контроля версий не нужно. Я погуглил, есть средство для оборачивания Bower в Browserify.
По Node, Express, Redis и MongoDB писать отдельные статьи, разумеется, не нужно. Но в статье по Derby требуется осветить все эти инструменты с полного нуля и в той мере, которая необходима для создания учебного приложения.
По поводу двух ваших вариантов, мне кажется, что второй пункт является логичным продолжением первого. Вы натолкнули меня на мысль заглянуть на TodoMVC.com — учебное приложение, выполненное на всех фреймворках, и Derby там уже есть! Причем там в README даже неплохая подборка ссылок.
Но вот пошагового туториала о настройке окружения и написании учебного приложения там нет. Берите готовенькое и разбирайтесь как сможете.
Так что можно взять в качестве цели именно TodoMVC.
Готов посильно участвовать в затее, но не знаю, чем я без знаний Derby и всего остального могу быть полезен.
По Node, Express, Redis и MongoDB писать отдельные статьи, разумеется, не нужно. Но в статье по Derby требуется осветить все эти инструменты с полного нуля и в той мере, которая необходима для создания учебного приложения.
По поводу двух ваших вариантов, мне кажется, что второй пункт является логичным продолжением первого. Вы натолкнули меня на мысль заглянуть на TodoMVC.com — учебное приложение, выполненное на всех фреймворках, и Derby там уже есть! Причем там в README даже неплохая подборка ссылок.
Но вот пошагового туториала о настройке окружения и написании учебного приложения там нет. Берите готовенькое и разбирайтесь как сможете.
Так что можно взять в качестве цели именно TodoMVC.
Готов посильно участвовать в затее, но не знаю, чем я без знаний Derby и всего остального могу быть полезен.
Для npm в package.json вы можете тоже прописывать git-репозитарии. Ну а то что добавлять npm модули в систему контроля версий или нет, тут зависит от приложения. Например если вы деплоите из git, то наверно лучше там же и держать всю папку node_modules.
Я смотрю Derby TodoMVC приложение как раз использует Bower. Но я всё равно не понимаю зачем он :-)
Кстати по поводу настройки окружения: Derby — это по сути обычное Express приложение. Можно использовать туториалы для Express.
Ну ок. С меня пара-тройка туториалов по Derby. С вас их изучение. Договорились?
Я смотрю Derby TodoMVC приложение как раз использует Bower. Но я всё равно не понимаю зачем он :-)
Кстати по поводу настройки окружения: Derby — это по сути обычное Express приложение. Можно использовать туториалы для Express.
Ну ок. С меня пара-тройка туториалов по Derby. С вас их изучение. Договорились?
Конечно. Буду первой жертвой. :D
Если можно, то в первом же материале затроньте тему с моделями и обновлением данных. Это, imo, самое интересное. Не хотите завести импровизированное русскоязычное коммьюнити? Я бы присоединился.
Хорошо.
Что значит «завести импровизированное русскоязычное коммьюнити»? Хочу наверно. Но что это? :-)
Что значит «завести импровизированное русскоязычное коммьюнити»? Хочу наверно. Но что это? :-)
Ну, например, гугл-группу, гугл+ группу или фейсбук группу для русскоязычных разработчиков под Derby. Хотя, наверное, это будет мертворожденная затея.
Есть англоязычная googlegroup. Там сидит народ со всего мира. Русские тоже есть. На самом деле я просто советую перечитать там все статьи хотя бы за последнее время чтобы понимать что происходит. Особенно интересны ответы от созадателей Nate, Brian, Joseph.
Вопросы тоже там задаются и все пытаются помочь кто чем может.
Вопросы тоже там задаются и все пытаются помочь кто чем может.
Я уже думал никто не возьмется и будет очередной «крутой» фрэймворк, до которого надо дорасти. Не надо никаких групп вконтактике/гугле/фэйсбуке. Достаточно активного обсуждения на SO как у метеора и ресурса с парой-тройкой туториалов. То есть так, чтобы хоть кто-то понял, а потом из тех кто понял кто-то еще и захотел поделиться знаниями. Потом как по PHP расплодится туториалов и всем станет хорошо, иначе будет метеор :)
У меня сильное желание постичь серверный js, так как знакомство с клиентским прошло кмк вполне отлично, но начинать с ноды со-товарищи вместо удобного фрэймворка как-то не хочется.
Так что жду с нетерпением туториалов.
У меня сильное желание постичь серверный js, так как знакомство с клиентским прошло кмк вполне отлично, но начинать с ноды со-товарищи вместо удобного фрэймворка как-то не хочется.
Так что жду с нетерпением туториалов.
SO = stackoverflow.com/?
Спасибо.
Буду чаще появляться на SO. Там можно как-нибудь подписаться на tag, чтобы уведомления приходили?
Буду чаще появляться на SO. Там можно как-нибудь подписаться на tag, чтобы уведомления приходили?
Можно
Как? :-)
Регистрируешься, переходишь по stackoverflow.com/tags, вбиваешь derbyjs, наводишь мышку на выбранный tag (derbyjs выделенный сереньким), ждешь пол секунды — всплывает небольшое окошко с описанием тега, в правом верхнем углу есть кнопочки «subscribe» и «rss», выбираешь нужную и, вуаля, готово.
Тогда уж лучше — education.mongodb.com/courses/10gen/M101JS/2013_October/about — сам его прошел (точнее сегодня последний день :) — хороший курс. На английском, но с субтитрами.
Азы Node, Express, Mongo — learn.javascript.ru/nodejs-screencast
Как вариант, хотя и скупой: github.com/codeparty/derby-examples
Вы не можете использовать derby отдельно от racer, ибо derby привязано к модели данных racer.В каком объеме в ToToMVC используется racer?
как у него дела с ограничением доступа к БД? к определённым полям, объектам?
к определённым полямКак я понял (на данный момент) объекты передаются целиком, отбора по полям нет.
Из документации:
Note that projections are not supported; only full documents may be returned.
Есть плагин для racer: racer-access
Но в данный момент ограничивать доступ можно только к колекциям или сущностям.
Ограничить доступ к полям нельзя. Это связано с тем, что это требует некоторого изменения работы share.js. Проблема известная. Находится в todo, так сказать.
Использовать примерно так:
Но в данный момент ограничивать доступ можно только к колекциям или сущностям.
Ограничить доступ к полям нельзя. Это связано с тем, что это требует некоторого изменения работы share.js. Проблема известная. Находится в todo, так сказать.
Использовать примерно так:
racerAccess = require 'racer-access'
derby.use racerAccess
store.allow 'change', 'users', (some usefull arguments) -> return true or false
Хотелось бы побольше узнать про OT в derby, в контексте конкурентного изменения произвольных моделей.
OT в объеме статьи в викепедии на примере конкурентного редактирования строки текста я понимаю; но обычно модель данных приложения куда сложнее, а различных мутирующих операций тоже намного больше. Весь этот уровень, где творится OT-магия — он прозрачен для разработчика?
Год назад все было намного проще — режим «кто последним записал, тот и выграл», плюс отдельно OT-подобный режим, который не работал :)
OT в объеме статьи в викепедии на примере конкурентного редактирования строки текста я понимаю; но обычно модель данных приложения куда сложнее, а различных мутирующих операций тоже намного больше. Весь этот уровень, где творится OT-магия — он прозрачен для разработчика?
Год назад все было намного проще — режим «кто последним записал, тот и выграл», плюс отдельно OT-подобный режим, который не работал :)
FAQ по OT
Если в двух словах: OT — это операционное преобразование. Каждая приходящая операция, перед тем как внести свою лепту в бд, преобразовывается, учитывая все предыдушие операции над текущими данными.
В OT многое зависит от типа данных. Самый простой вариант — это строка. В racer, например — json. Здесь — все типы, которые поддерживает share.js. Как вы понимаете ничего не мешает добавить туда свой тип.
Уровень довольно прозрачен, но требует определенных знаний.
Ну а вообще конечно, как говорят, курите исходники. Есть только один человек, который точно знает как работает эта чертова штуковина.
Вы абсолютно правильно сказали, что в Derby 0.3 была оптимистичная модель разрешения конфликтов и подобие OT. В Derby 0.5 добавили share.js, для чего потребовалось практически полностью переписать racer. Сейчас эта штука работает крайне хорошо и стабильно.
Если в двух словах: OT — это операционное преобразование. Каждая приходящая операция, перед тем как внести свою лепту в бд, преобразовывается, учитывая все предыдушие операции над текущими данными.
В OT многое зависит от типа данных. Самый простой вариант — это строка. В racer, например — json. Здесь — все типы, которые поддерживает share.js. Как вы понимаете ничего не мешает добавить туда свой тип.
Уровень довольно прозрачен, но требует определенных знаний.
Ну а вообще конечно, как говорят, курите исходники. Есть только один человек, который точно знает как работает эта чертова штуковина.
Вы абсолютно правильно сказали, что в Derby 0.3 была оптимистичная модель разрешения конфликтов и подобие OT. В Derby 0.5 добавили share.js, для чего потребовалось практически полностью переписать racer. Сейчас эта штука работает крайне хорошо и стабильно.
Ага спасибо, нашел у них описание поддерживаемых операций над json.
Краткое резюме как я понял — все операции имеют первым аргументом путь. Если путь пролегает через массив(-ы), индексы будут скорректированы с учетом конкурентных операций удаления и вставок в эти массивы. Операции типа insert, delete, replace object имеют семантику «кто последний записал, тот и выиграл» — то есть путь до места модификации OT скорректирует как надо, а сам объект будет вставлен как есть, никакой магии.
Can OT solve semantic consistency problems? Ответ — из фака — нет может.
Я это понимаю так — если OT-магия применяется на уровне типов данных то сохранения консистентности в модели данных приложения («семантическая корректность») никто не обещает.
Ну то есть можно наверно использовать share.js как OT движок и тщательно определять все application-specific операции и их трансформации. Но это какую голову надо иметь!
Или использовать типы данных с поддержкой OT как есть, потенциально получая сломанные данные в результате работы OT («сементическая корректность»). Как такие вещи вобще тестировать?
В общем картина получается безрадостная :(
Краткое резюме как я понял — все операции имеют первым аргументом путь. Если путь пролегает через массив(-ы), индексы будут скорректированы с учетом конкурентных операций удаления и вставок в эти массивы. Операции типа insert, delete, replace object имеют семантику «кто последний записал, тот и выиграл» — то есть путь до места модификации OT скорректирует как надо, а сам объект будет вставлен как есть, никакой магии.
В OT многое зависит от типа данных.Мне кажется, начинать стоит с модели данных приложения, и операций над этой моделью определяемых приложением. Разумеется высокоуровневые application-specific операций оперируют конкретными типами данных. Но
Can OT solve semantic consistency problems? Ответ — из фака — нет может.
Я это понимаю так — если OT-магия применяется на уровне типов данных то сохранения консистентности в модели данных приложения («семантическая корректность») никто не обещает.
Ну то есть можно наверно использовать share.js как OT движок и тщательно определять все application-specific операции и их трансформации. Но это какую голову надо иметь!
Или использовать типы данных с поддержкой OT как есть, потенциально получая сломанные данные в результате работы OT («сементическая корректность»). Как такие вещи вобще тестировать?
В общем картина получается безрадостная :(
Вот что называется «зри в корень» :-) Те вопросы и проблемы которые вы поднимаете очень важны.
Я не считаю себя экспертом в OT и наверное лучше эти вопросы задать Joseph`у. Я думаю он с радостью на них ответит. Но как вы сами пишите share.js для типа json оперирует целыми объектами. Не это ли обеспечивает «семантическую корректность»?
Я не считаю себя экспертом в OT и наверное лучше эти вопросы задать Joseph`у. Я думаю он с радостью на них ответит. Но как вы сами пишите share.js для типа json оперирует целыми объектами. Не это ли обеспечивает «семантическую корректность»?
Не нужно паники. Я разобрался.
Как я и предположил в соседнем комментарии, share.js оперирует целыми сущностями (объектами в бд с ид). Для этого у каждой сущности есть версия, которая меняется при любых изменениях данной сущности. Таким образом обеспечивается «семантическая корректность». То есть данные не теряются ни при каких обстоятельствах.
По поводу application-specific.
Для того чтобы добавить share.js в racer, ее пришлось «слегка» переписать (0.6 — 0.7). Таким образом share.js уже является application-specific, в том плане, что это OT для веб-приложений.
Ну а головы у создателей Derby — то что нужно:
Nate раньше работал продакт-менеджером Google Search Images.
Brian — создатель everyauth и mongoose
Joseph писал OT для Google Waves.
Как я и предположил в соседнем комментарии, share.js оперирует целыми сущностями (объектами в бд с ид). Для этого у каждой сущности есть версия, которая меняется при любых изменениях данной сущности. Таким образом обеспечивается «семантическая корректность». То есть данные не теряются ни при каких обстоятельствах.
По поводу application-specific.
Для того чтобы добавить share.js в racer, ее пришлось «слегка» переписать (0.6 — 0.7). Таким образом share.js уже является application-specific, в том плане, что это OT для веб-приложений.
Ну а головы у создателей Derby — то что нужно:
Nate раньше работал продакт-менеджером Google Search Images.
Brian — создатель everyauth и mongoose
Joseph писал OT для Google Waves.
Таким образом обеспечивается «семантическая корректность». То есть данные не теряются ни при каких обстоятельствах.Семантическая корректность это другое. В примере из FAQ речь идет про соответствие строки нормам английского языка. Обе правки сами по себе оставляют текст в грамматически—корректном состоянии, а объединение операций дает некорректную строку.
edit1(ins,11,'s'): 'OT preserve operation intention' -> 'OT preserves operation intention'
edit2(ins,2,'can '): 'OT preserve operation intention' -> 'OT can preserve operation intention'
result: 'OT can preserves operation intention'
Точно так же, как текст на естественном языке, объекты приложения должны удовлетворять определенным ограничениям. Каким именно — зависит от приложения.
Хороший пример сходу придумать не могу (избыточность хранимых данных не в счет).
Да, видимо, я так и не разобрался. Вы определенно в чём-то правы.
Задал ваш вопрос Joseph`у. Он ответил. Предлагаю переместить нашу дискуссию туда.
Задал ваш вопрос Joseph`у. Он ответил. Предлагаю переместить нашу дискуссию туда.
Клиенты могут уходить на долгое время в оффлайн, изменять данные в своих моделях, после этого их данные запишутся в бд с учетом изменений от других клиентов за это время.
Оба клиента ушли в офлайн оба сделали какие-то изменения. Вернулись. Итоговый результат зависит от установленного вермени у клиента?
Оба клиента ушли в офлайн оба сделали какие-то изменения. Вернулись. Итоговый результат зависит от установленного вермени у клиента?
Привязка идет не ко времени, а к версии данных. Разрешние конфликтов осуществляется с помощью OT и зависит от операций.
При уходе в оффлайн у обоих актуальная версия 100500 оба делают одну правку. У обоих 100501. Правки сет на 1 поле, но значения разные. Кто победил?
Ничья :-)
Если честно, то не знаю. Чуть выше в комментариях идет обсуждение OT и дальше там ссылка на ответы Joseph`а.
Кто разберется и распишет в двух словах, тот получит водокачку!
Если честно, то не знаю. Чуть выше в комментариях идет обсуждение OT и дальше там ссылка на ответы Joseph`а.
Кто разберется и распишет в двух словах, тот получит водокачку!
Давайте уж лучше вы.
В этом случае у OT нету механизмов учесть обе правки. Будет оптимистичная модель. Одно из изменений потеряется.
Для большинства приложений можно абстрагироваться от OT и думать об этом как о некотором черном ящике, который разрешает конфликты. В данной ситуации, например, OT из коробки смерижло бы без проблем операции с массивами, со строкой или инкремент числа. Но в некоторых случаях (как в вашем примере), при определенных условиях, данные могут теряться. Если это критично, то нужно опускаться на уровень OT и учитывать его работу. Также возможно содание application-specific типов данных.
Эх. В чем только не разобрался за эти дни с вами. :-) Спасибо.
Для большинства приложений можно абстрагироваться от OT и думать об этом как о некотором черном ящике, который разрешает конфликты. В данной ситуации, например, OT из коробки смерижло бы без проблем операции с массивами, со строкой или инкремент числа. Но в некоторых случаях (как в вашем примере), при определенных условиях, данные могут теряться. Если это критично, то нужно опускаться на уровень OT и учитывать его работу. Также возможно содание application-specific типов данных.
Эх. В чем только не разобрался за эти дни с вами. :-) Спасибо.
Почему вебсокет не гарантирует порядок? Он же по TCP, а он гарантирует и доставку и порядок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tutorial Derby.js