Продолжение планирую. В следующей статье думаю написать какое-нибудь не очень сложное приложение.
MVC рассмотрим. Что еще не понятного?
Документация скудная, согласен, исправляем.
Для такого размера приложения — нормально свалить всё в кучу. Но в общем вы правы.
Вот что называется «зри в корень» :-) Те вопросы и проблемы которые вы поднимаете очень важны.
Я не считаю себя экспертом в OT и наверное лучше эти вопросы задать Joseph`у. Я думаю он с радостью на них ответит. Но как вы сами пишите share.js для типа json оперирует целыми объектами. Не это ли обеспечивает «семантическую корректность»?
Я конечно почитаю, но вы можете подробнее расписать? Как будет при RDB, как при AOF? Какая скорость, какая надежность? Я думаю многим будет интересно и полезно. Если есть какие-то тесты, вообще будет здорово. Тут даже пост можно написать.
Marionette.js — это расширение Backbone и по сути тот же mvc на клиенте фреймворк, что и Angular.
Если вы замените в таблице Angular на Marionette, то результаты практически не изменятся.
Если в двух словах: OT — это операционное преобразование. Каждая приходящая операция, перед тем как внести свою лепту в бд, преобразовывается, учитывая все предыдушие операции над текущими данными.
В OT многое зависит от типа данных. Самый простой вариант — это строка. В racer, например — json. Здесь — все типы, которые поддерживает share.js. Как вы понимаете ничего не мешает добавить туда свой тип.
Уровень довольно прозрачен, но требует определенных знаний.
Вы абсолютно правильно сказали, что в Derby 0.3 была оптимистичная модель разрешения конфликтов и подобие OT. В Derby 0.5 добавили share.js, для чего потребовалось практически полностью переписать racer. Сейчас эта штука работает крайне хорошо и стабильно.
JugglingDB — это интересный проект. Спасибо за ссылку.
Но в derby он будет как третия рука. То есть добавит абстракции, а главное его достоинство — бд на клиенте не будет использовано.
Адаптеры для live-db тоже своеобразные (там же OT) и не факт что JugglingDB тут пригодится тоже.
Есть англоязычная googlegroup. Там сидит народ со всего мира. Русские тоже есть. На самом деле я просто советую перечитать там все статьи хотя бы за последнее время чтобы понимать что происходит. Особенно интересны ответы от созадателей Nate, Brian, Joseph.
Вопросы тоже там задаются и все пытаются помочь кто чем может.
Потому-что Redis — это In-memory бд. Все данные лежат в оперативной памяти и их размер ограничен как вы понимате. Конечно вы можете купить много памяти, но это всегда ограниченно. Для каких-то проектов это возможно. Я согласен.
Вторая проблема — это то что Redis с настройками по умолчанию сохраняет данные на диск периодически. То есть большую часть времени данные не синхронизированны и при неполадках потеряются. Можно поменять настройки (чтобы записывалось на диск после каждой операции), но тогда скорость работы Redis сильно упадет и по сути сведет на нет все его достоинства.
Адаптера для Redis нету. Зато есть адаптер для mongo.
Redis используется для Pub-sub и кэша операций. Данные хранятся в mongo.
Я к сожалению не силен в mysql, не скажу. Возможно.
Мне интересно также в чем необходимость использовать именно mysql? Может и Mongo на худой конец сойдет? А? :-)
MVC рассмотрим. Что еще не понятного?
Документация скудная, согласен, исправляем.
Для такого размера приложения — нормально свалить всё в кучу. Но в общем вы правы.
Буду чаще появляться на SO. Там можно как-нибудь подписаться на tag, чтобы уведомления приходили?
Я не считаю себя экспертом в OT и наверное лучше эти вопросы задать Joseph`у. Я думаю он с радостью на них ответит. Но как вы сами пишите share.js для типа json оперирует целыми объектами. Не это ли обеспечивает «семантическую корректность»?
Я конечно почитаю, но вы можете подробнее расписать? Как будет при RDB, как при AOF? Какая скорость, какая надежность? Я думаю многим будет интересно и полезно. Если есть какие-то тесты, вообще будет здорово. Тут даже пост можно написать.
Если вы замените в таблице Angular на Marionette, то результаты практически не изменятся.
Если в двух словах: OT — это операционное преобразование. Каждая приходящая операция, перед тем как внести свою лепту в бд, преобразовывается, учитывая все предыдушие операции над текущими данными.
В OT многое зависит от типа данных. Самый простой вариант — это строка. В racer, например — json. Здесь — все типы, которые поддерживает share.js. Как вы понимаете ничего не мешает добавить туда свой тип.
Уровень довольно прозрачен, но требует определенных знаний.
Ну а вообще конечно, как говорят, курите исходники. Есть только один человек, который точно знает как работает эта чертова штуковина.
Вы абсолютно правильно сказали, что в Derby 0.3 была оптимистичная модель разрешения конфликтов и подобие OT. В Derby 0.5 добавили share.js, для чего потребовалось практически полностью переписать racer. Сейчас эта штука работает крайне хорошо и стабильно.
Но в derby он будет как третия рука. То есть добавит абстракции, а главное его достоинство — бд на клиенте не будет использовано.
Адаптеры для live-db тоже своеобразные (там же OT) и не факт что JugglingDB тут пригодится тоже.
Вопросы тоже там задаются и все пытаются помочь кто чем может.
Что значит «завести импровизированное русскоязычное коммьюнити»? Хочу наверно. Но что это? :-)
Вторая проблема — это то что Redis с настройками по умолчанию сохраняет данные на диск периодически. То есть большую часть времени данные не синхронизированны и при неполадках потеряются. Можно поменять настройки (чтобы записывалось на диск после каждой операции), но тогда скорость работы Redis сильно упадет и по сути сведет на нет все его достоинства.
Адаптера для Redis нету. Зато есть адаптер для mongo.
Redis используется для Pub-sub и кэша операций. Данные хранятся в mongo.
Проблема и правда не актуальна.
Мне интересно также в чем необходимость использовать именно mysql? Может и Mongo на худой конец сойдет? А? :-)