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