logo
logo

Форум Синхронизация в облаке

создать новую тему раскрыть все
Синхронизация в облаке radonic 19/02/2016 20:34 #написать ответ
Добрый вечер!
Есть ли какое-либо решение по конфликтующим копиям БД в облачном хранилище при синхронизации с нескольких устройств одновременно?
Спасибо!
могу предложить Meinfin 20/02/2016 12:44 #написать ответ
небольшую собственную поделку: http://dervish.ru/forum-theme.2829/#p16713
Тут речь немного о другом Vladimir 02/04/2016 04:25 #написать ответ
База хранится в облаке. Называется ac.cash.
Зашёл я с одного компьютера в режиме офлайн, внёс данные, сохранил, программу закрыл.
Зашёл с другого, возможно даже в онлайне, внёс изменения, сохранил, закрыл.
Файл залился на облако.
Когда первый компьютер выйдет в онлайн - возникнет конфликт версий файла.
И Яндекс.Диск, который я использую, смело и без предупреждений создаст файл ac (2).cash.
О том, что это произошло - становится понятно только когда увидишь копию или когда начнёшь искать изменения, которые точно вносил.
И семафор тут не поможет)
Можно сделать костыль, который будет хранить список файлов *.cash  в папке и при появлении нового файла предупреждать пользователя.
А со стороны AbilityCash для таких и подобных случаев возможно был бы полезен функционал слияния баз - искать отличия в двух базах и сливать в одну.
боюсь - это фантастика) Meinfin 04/04/2016 14:27 #написать ответ
мне кажется это даже в самой программе не просто реализовать, не говоря уже о каких-то внешних скриптах.
Вот к примеру: проехали вы в автобусе, внесли в офлайн базу запись, открыли базу в др. месте - нет этой транзакции, внесли еще раз. Потом первый комп стал онлайн, базы нужно синхронизировать - как программа поймет где правильная запись?
 
PS
в последней версии моего скрипта есть проверка на наличие  копии для Dropbox по маске "*Конфликтующая копия*.cash"
 
PPS
для возможности отлова дублирующих записей в базе я просил автора добавить возможность отображения даты внесения записи http://dervish.ru/bugs-item.404/
Не просто реализовать что? Vladimir 04/04/2016 14:51 #написать ответ
Первый комп стал онлайн - облако создаёт конфликтующую копию. Программа видит новый файл в папке и интересуется у пользователя - что происходит?
Если пользователь говорит "это косяк, надо сливать", то программа показывает список различающихся операций и пользователь принимает решение по каждой операции - забрать операцию из конфликтующей версии или оставить как есть в основной. После слияния программа предлагает удалить конфликтующую версию файла.
Вполне себе user-friendly сценарий, и ничуть не фантастичный.
P.S. Скрипт конечно дело хорошее, но костыльное) Я сам программист и могу написать ланчер, который будет работать по описанному выше сценарию. Но реализация в самой программе - это более естественный путь. Тем более в случае зашифрованной базы ланчер не спасёт.  Это лично моё мнение и не является истиной в последней инстанции))
А я полностью с вами согласен. Meinfin 05/04/2016 12:30 #написать ответ
Для меня вообще возможность кастомизации интерфейса и поведения - это очень важный пункт при выборе программы. Инструмент должен быть удобным. К моему сожалению, автор считает что инструмент в первую очередь должен быть простым.
>ланчер не спасёт
Смотря какой лаунчер. По идее лаунчер может сделать выборку последних 200 строк и сравнить их. Но и тут вы правы - это все ужасные костыли)
счас договоритесь... zubrizavr 13/04/2016 02:11 #написать ответ
до того, что нужно чтобы было несколько баз, для каждого экземпляра программы. И чтобы по нажатию кнопки содержимое этих баз синхронизировалось в мастер-базу, а по завершении чтобы эти базы подменялись мастер-базой.
Я человек далёкий от всего этого и не вижу другого выхода нормального.
очень хорошая идея) Meinfin 13/04/2016 10:51 #написать ответ
вообще с синхронизацией беда. В случае каких-то расхождений исправить можно только руками. Было бы крайне здорово, если бы при импорте появилась галочка "Не импортировать дубликаты" или что-то подобное.
Мы же про облако... Vladimir 13/04/2016 12:51 #написать ответ
при работе с которым получим конфликт файлов мастер-базы в точности по тому же сценарию, который я описал
про облако Meinfin 13/04/2016 15:18 #написать ответ
но в контексте синхронизации. Если будет реализован механизм синхронизации, то конфликты если и будут, то безболезненные, программа сможет слить несколько баз в одну.
но это все мечты, на данном этапе.
хотя программа постоянно развивается - возможно когда-то и будет что-то подобное реализовано.
В чём отличия Vladimir 16/04/2016 05:31 #написать ответ
Между "сливать разные версии баз" в текущем варианте и "сливать разные версии мастер-базы"?
позволю себе не согласиться zubrizavr 16/04/2016 19:16 #написать ответ
т.к. по моей схеме каждый экземпляр работает со своей базой хранящейся в облаке.
А при синхронизации все базы будут лочиться, т.е. станут недоступны до окончания процесса синхронизации.
Подождите Vladimir 17/04/2016 05:34 #написать ответ
Тогда мы теряем один из главных плюсов облака - автоматическую синхронизацию без участия пользователя. Т.к. синхронизироваться с мастер-базой нужно будет исключительно онлайн.
есть одно НО zubrizavr 17/04/2016 10:55 #написать ответ
Итак, главная проблема синхронизации с облаком - как не перетереть файл базы, чтобы не потерять изменения сделанные
через N-го клиента.
 
В случае использования некоего штатного "облаконизатора"(яндекс диск, дропбокс, гуглдиск) у нас файлы заливаются по хотению и разумению самого "облаконизатора".
Отсюда я делаю вывод что ему пофиг, главное залить файл поновее.
Значит нужен механизм который будет смотреть что можно, а что нельзя.
Для меня, как не специалиста, очевидным является использование разных баз(чтобы "облаконизатор" не перезаписывал) и некоей главной базы, в которую abilitycash будет импортировать все различия из баз.
А дальше уже от извращённой фантизии программиста будет зависить как именно эти базы будут собираться в одну.
Т.е. я считаю что проблема будет, пока будет один файл базы.
 
Если же интегрировать работу с облаками в саму программу, то нам надо будет чтобы она сравнивала содержимое локального файла базы... причём он должен лежать в не синхронизируемой папке, потому что иначе "облаконизатор" его просто зальёт в облако вместо того, который там был... получается бредово
Ну, на то я и не специалист, чтобы найти повод для удивления где захочу
Не совсем так Vladimir 17/04/2016 11:15 #написать ответ
Облако создаёт дубликат файла в случае конфликта, а не затирает.
В итоге принципиальной разницы нет, откуда взялась вторая база -  сам пользователь создал или облако создало из-за конфликта.
У меня две базы и три компьютера, на которых я с ними работаю. По Вашей схеме у меня получится целый зоопарк с необходимостью постоянной ручной синхронизации %) А по моей - будут редкие случаи синхронизации, и только в том случае, если возник конфликт баз.