0001872: Добавить возможность сохранять тайлы разных версий в кэш Беркли

Notes
(0010950) vasketsov (manager) 31-03-2013 10:03	Планируешь типа как через VersionInCache делать, или наоборот чтобы версии одного тайла были физически всегда в одной БД?

(0010951) zed (manager) 31-03-2013 10:41	>чтобы версии одного тайла были физически всегда в одной БД Так.

(0010952) vdemidov (manager) 31-03-2013 11:57	Только, пожалуйста, сделай его отдельным типом кэша, а не волшебными переключателями в zmp

(0010953) zed (manager) 31-03-2013 12:03	Логика будет такая: если строка VersionInfo при обращении к хранилищу будет что-то содержать, то будет происходить версионное чтение/запись. А если строка пустая - будет работать как сейчас. Плодить лишних типов хранилищ или переключателей в zmp нет никакого желания.

(0010954) zed (manager) 31-03-2013 13:21	Хм, столкнулся с тем, что если одновременно будут производиться манипуляции (запись или удаление) с одним и тем же тайлом из разных потоков/приложений, то возможно несогласованное состояние метаинформации и данных, касательно этого тайла. Вот и думаю, насколько это критично? C одной стороны, метаинформация постепенно сама придёт в согласованное состояние (если при запросе тайла увидит, что в метаинформации он есть, а на самом деле его нет, или есть, но другой версии), с другой стороны можно критический участок тупо залочить мютексом (но насколько сильно это всё поставит нас на ручник - вопрос). Но по-моему, вероятность, что пользователь напорится на несогласованные данные очень низкая. А если напорится - сам виноват, потому как не стоит одновременно изменять данные из разных мест для одного и того же участка. Это же как ни как локальная БД, для single user mode.

(0010956) zed (manager) 31-03-2013 17:46	Запушил изменения в тестовую ветку. Из важного там пока что нету проверки/восстановление метаинформации до согласованного состояния, а так же не доделана фича, чтобы при записи тайла с новой версией, если в кэше уже есть тайл с таким же CRC, запись самого тайла не производилась, а обновлялась лишь метаинформация (должна прописаться новая версия и дата). Хотя, над фичей ещё подумаю - при проблемах с согласованным состоянием, наверное надёжней будет всё же перезаписывать старый тайл.

(0011036) zed (manager) 07-04-2013 12:21	Ну, вроде с большего версионность готова. Тестовая сборка: SASPlanet.MultiVersions.BerkeleyDB.130407.7z Сделано так, чтобы пользователь вообще никак не почувствовал, что в Беркли что-то там поменялось. Однако, если юзер пользуется полем Version в настройках карты, он обнаружит приятный бонус, что после очередного обновления версии, у него всё ещё остаётся возможность включить старую версию - при обновлении карты старый снимок не затрётся новым. Если же поле Version пустое и никак не используется, то никаких отличий в кэше не будет. Единственное ограничение - если использовалось поле Version при записи в кэш, то старые версии САСа в таком кэше ничего не найдут и будут качать заново.

(0011075) Papazol (reporter) 14-04-2013 05:41	1. Нужен пошаговый алгоритм перевода неверсионного кэша в версионный. В частности, как слить в единый версионный кэш несколько неверсионных. 2. Как работать с версионным кэшем: просмотр, скачивание, удаление и т. д. 3. Что нужно написать в zmp для версионного (вновь создаваемого) кэша. Подробности ВЕСЬМА приветствуются.

(0011076) zed (manager) 14-04-2013 18:35	Разработка как бы на том этапе, когда принимаются пожелания, как и что должно работать. Т.е. это вы мне напишите инструкцию, как вы себе представляете работу с версионным кэшем, а там уже подумаем, что можно сделать.

(0011077) Papazol (reporter) 14-04-2013 20:37 edited on: 14-04-2013 20:45	Хорошо, вот мои пожелания. 1. Разбив кэш на версии, имеющие названия либо номера (но названия было бы более правильно), мы как бы создаём несколько виртуальных папок, имеющих соответствующие названия, с которыми можно работать как с обычным кэшем, то есть поддерживаются все операции, имеющиеся в программе. 2. Версионность какого-либо кэша (соответствующей карты) должна быть определена в zmp с помощью некоторой записи. 3. При открытии карты, имеющей в zmp запись о версионности, в программе должен появляться новый пункт выпадающего меню, в котором можно переключать показ существующих версий и создавать новую версию. Либо на панели инструментов дополнительная закладка. 4. Должна быть возможность скопировать в любую существующую или вновь созданную версию версионного кэша содержимое любого другого кэша, в том числе и из одной версии в другую одного и того же кэша. 5. Если в указанной для копирования версии уже имеются тайлы, которые мы намереваемся туда скопировать, программа должна сообщить об этом и предложить создать новую версию. Здесь возможны косяки, связанные с частичным наложением снимков друг на друга, поэтому проверять придётся весь кэш до копирования, что может занять некоторое время. 6. При скачивании возможна та же проблема, Как её решать, я пока не придумал. 6. Должна быть возможность удалить любую версию существующего кэша. 7. Должна быть возможность защитить любую существующую версию от перезаписи, аналогично UseDwn=0 в обычном кэше.

(0011079) zed (manager) 15-04-2013 06:23	vdemidov >Только, пожалуйста, сделай его отдельным типом кэша, а не волшебными переключателями в zmp zed >Сделано так, чтобы пользователь вообще никак не почувствовал, что в Беркли что-то там поменялось Papazol > Версионность какого-либо кэша (соответствующей карты) должна быть определена в zmp с помощью некоторой записи. Таки конфликт наблюдается. >Если в указанной для копирования версии уже имеются тайлы Если следовать логике, что каждый отдельный снимок лежит в отдельной версии, то никаких наложений не будет. Т.е. по задумке, версионность в САС - аналог исторического режима в Google Earth. >аналогично UseDwn=0 в обычном кэше Это не защищает от перезаписи, а отключает загрузку из интернета.

(0011080) vasketsov (manager) 15-04-2013 06:28	Не вижу пока что конфликта: >должна быть определена в zmp с помощью некоторой записи Ну это запись Version=xxxxxxxxxx и будет )) Более интересным является вопрос, как для выделенной области установить некую версию или выполнить фактически перенос тайла между версиями, и можно ли это делать в рамках этого же кэша (тайлы перетасовать).

(0011087) Papazol (reporter) 15-04-2013 14:16	Запись Version=xxxxx что означает? Если бы было Version=1, то понятно, что данный кэш версионный, если ничего или 0 - то обычный. >Если следовать логике, что каждый отдельный снимок лежит в отдельной версии, то никаких наложений не будет. Т.е. по задумке, версионность в САС - аналог исторического режима в Google Earth.< Только GE рид онли, а здесь можно и скачивать, и удалять. Обидно будет, собрав снимки, которые больше нельзя скачать, по ошибке, включив не ту версию, переписать в ней некоторое количество тайлов. А такое может произойти, если включен режим "Интернет". По идее, режим "Интернет" для версионного кэша вообще не должен включаться. А если мы начнём копировать выборочные снимки из других кэшей, и некоторые тайлы наложатся, что будет делать программа? Конечно, если пользователь всё заранее проверил и уверен, что снимки не пересекаются, тогда проблем нет. Но на все 100 быть в этом уверенными нельзя, защита от дурака обязана быть. Можно было бы тупо автоматически создавать новую версию и совпадающие тайлы кидать в неё, но тогда впоследствии разобраться, откуда что где взялось, будет весьма трудно. >вопрос, как для выделенной области установить некую версию< ИМХО, только копированием. Исходник должен остаться нетронутым. >выполнить фактически перенос тайла между версиями, и можно ли это делать в рамках этого же кэша (тайлы перетасовать)< На мой дилетантский взгляд, проблем здесь не должно быть.

(0011088) zed (manager) 15-04-2013 16:31	>Запись Version=xxxxx что означает? Вместо xxxx - подставляется версия (строка). В GoogleSat.zmp эта переменная уже используется и по-умолчанию Беркли считает этот кэш версионным. Если строка Version пустая или отсутствует, то кэш неверсионный. >А если мы начнём копировать выборочные снимки из других кэшей, Ну, при копировании защититься довольно легко (небольшой доработкой), а вот с режимом "Интернет" возможны проблемы, да. И как это решить не очень ясно. >ИМХО, только копированием. Исходник должен остаться нетронутым. И зачем вам в одном файле кэша сразу 2 (и более) идентичных тайла? Или скажем так, можно оставить один неверсионный и один версионный, но если мы меняем версию у версионного тайла, то просто нужно удалить старую версию и записать новую.

(0011089) vasketsov (manager) 15-04-2013 17:50	>По идее, режим "Интернет" для версионного кэша вообще не должен включаться Хм. Я бы сказал наоборот: версионный кэш не боится затирания, если он реально версионный, и номер версии правильный. Например, если следить за номером версии гугло-, яндексо- или бингоспутника - новые тайлы прилетят, только если номер версии на сервере сменился. Соответствено слежение за версиями картосервисов решает эту проблему. А "интернет" там или область выделяется - совершенно не принципиально. >если мы начнём копировать выборочные снимки из других кэшей, и некоторые тайлы наложатся Как только для беркли будет возможность указать версию при копировании области кэша - можно будет копировать из неверсионного кжша сразу с указанием нужной версии. И затирания разными версиями соседних версий не будет. >тупо автоматически создавать новую версию и совпадающие тайлы кидать в неё Если тайлы разные и страшно их затереть - не включаем переписывание существующих и включаем перенос - всё что не переписано, по идее должно остаться в исходном кэше. А автосоздание новой версии - это страшный моветон. >Или скажем так, можно оставить один неверсионный и один версионный А я вот не втыкаю, зачем оно надо. По логике "без версии" можно рассматривать как некую зарезервированную версию, которая никак не может реализоваться при указании реальной версии (например версия "" для гугла). То есть принципиальным различиям между версионными и неверсионными тайлами в одном смешанном кэше беркли, если он одновременно и версионный и нет, просто неоткуда взяться. Разве что какая-то историческая совместимость. Так что по идее функциональности копирования (точнее переноса) кэша самого в себя по выделенной области (на закладке копирования кэша) с указанием непустой версии или с указанием пустой версии (в смысле галочка включена, а значение или пустое или нет) более чем достаточно, чтобы раскидать тайлы по версиям.

(0011092) zed (manager) 15-04-2013 19:19	Ещё одна тестовая сборка: SASPlanet.MultiVersions.BerkeleyDB.130415.7z - Сделано копирование выделенной области с возможностью указания версии - Добавлена обработка ошибок при чтении битых тайлов из кэша - Изменены дефолтные параметры энвайронмента для повышения быстродействия и устойчивости кэша к сбоям

(0011093) vdemidov (manager) 15-04-2013 19:56	Но в любом случае, мне хочется иметь неверсионный беркли кэш и при этом возможность указывать версию при закачке. Поэтому я и прошу отдельный типом кэша то что ты делаешь.

(0011094) zed (manager) 15-04-2013 20:06	Ок, сделаю завтра отдельный тип кэша и смерджу ветку - дальше можно будет ковырять уже в основной ветке.

(0011098) Papazol (reporter) 16-04-2013 04:42	>Вместо xxxx - подставляется версия (строка). В GoogleSat.zmp эта переменная уже используется и по-умолчанию Беркли считает этот кэш версионным.< Тогда нужно толкование. Не будем забывать, что для версионного кэша используется один zmp, а версий (в данном кэше) может быть много. Зачем в zmp прописывать одну из них? А остальные где пишутся? >если следить за номером версии гугло-, яндексо- или бингоспутника - новые тайлы прилетят, только если номер версии на сервере сменился< Для сервисов, у которых номера версий не входят в URL, но тем не менее существуют, тоже ведь версионность должна быть. А запросы-то одинаковые что для предыдущей версии, что для следующей, только сами тайлы заменены. Вот тут и возможно случайно затереть/перезаписать ценный снимок. И вообще, связывать запросы на тайлы с названиями версий неправильно, это независимые вещи. Если нужно сделать их зависимыми, это отдельная история. >И зачем вам в одном файле кэша сразу 2 (и более) идентичных тайла?< Речь идёт о переносе снимков из существующих кэшей в один версионный. Например, у меня есть желание слить в один кэш все имеющиеся снимки DG. Сейчас каждый из них имеет свой zmp, свою папку в общем кэше. Вот при копировании любой из этих папок в другой кэш и имеет смысл сохранить исходник, мало ли что. >не включаем переписывание существующих и включаем перенос - всё что не переписано, по идее должно остаться в исходном кэше< Переписывание существующих - операция при версионном кэше лишняя. Если эти существующие изменились - добро пожаловать в новую версию, иначе зачем это всё. Должно быть копирование без замены существующих, и тут возникает вопрос, что делать, если существующий дублируется новым. Здесь, как всегда, два варианта: либо аборт, либо новая версия. Но выяснить, есть ли дубли, нужно до начала копирования, типа как в Total Commander'е. Если выяснится, что дубли есть, программа предлагает либо всё прекратить, либо создать новую версию и копировать в неё.

(0011099) zed (manager) 16-04-2013 07:08	>Зачем в zmp прописывать одну из них? А остальные где пишутся? Прописываем ту, которую хотим увидеть или в какую хотим качать. И лучше писать не в zmp, а в параметрах карты через гуй. А сами версии (список доступных) лежат в кэше и для конкретного тайла они выводятся в менюшке по ПКМ. >И вообще, связывать запросы на тайлы с названиями версий неправильно, это независимые вещи. Если нужно сделать их зависимыми, это отдельная история. Сейчас они как раз-таки связаны, и очень сильно. Чтобы разделить версию для запросов и версию для отображения, нужно ковырять САС в неизвестном направлении. И наверное будет проще удалить переменную Version из скриптов и использовать этот параметр только для кэша. >Вот при копировании любой из этих папок в другой кэш и имеет смысл сохранить исходник, мало ли что. Ну так естественно, источник кэша никто не будет удалять, если вы сами об этом не попросите соответствующей галочкой. Тут всё аналогично переносу из тайлового кэша в БД. >Переписывание существующих - операция при версионном кэше лишняя. Хм, вероятно да, если идёт запись в кэш другого тайла под той же версией, то можно по-умолчанию запретить такую операцию (сейчас разрешена). Плюс, как-то нужно сообщать юзеру, что он делает что-то не то.

(0011100) vasketsov (manager) 16-04-2013 08:01	>это независимые вещи. Если нужно сделать их зависимыми, это отдельная история На самом деле ровно наоборот. Изначально версия была только одна. Если надо разные версии для скачки и отображения из хранилища - это должна быть отдельная глобальная доработка, никаким образом непосредственно к беркли отношения не имеющая. >нужно ковырять САС в неизвестном направлении Направление известно, доработка простая, разве что надо очень аккуратно всё сделать. Достаточно добавить ещё один параметр кроме Version, и чтобы качалка использовала именно его. Но лениво, лично мне не упирается, и всё такое прочее. Заодно кстати сделать (это будет очень близко и там же), чтобы в форме прогресса скачки "зафиксировать" версию какой-нибудь залипающей кнопкой или галочкой, чтобы любые последующие изменения версий на ЭТУ скачку не влияли. Появляется возможность качать разные версии в фоне, а смотреть совсем другую. Это если кто-то тикет новый соберётся написать, кому совсем тяжко с одной версией жить. >Переписывание существующих - операция при версионном кэше лишняя 1. Это только в идеальном мире, где нет ошибок, и картосервисы отдают только тайлы запрошенной версии. Как минимум для устранения ошибок такая операция нужна. 2. Сейчас если не включено переписывание существующих, дополнительно выполняется запрос, а есть ли тайл в целевом хранилище. Так что если даже целевое хранилище пустое - лучше включать галочку переписывания поверх, быстрее будет. Это конечно просто потому что сохранение тайла внутри хранилища нельзя пока что выполнить с признаками типа "если уже есть - не сохранять" или "если уже есть и размера N - не сохранять" и вернуть результат, был ли фактически сохранён тайл, и по какой причине не был сохранён. Но пока руки не дошли - только так. >нужно сообщать юзеру, что он делает что-то не то В мозг приходит только общая для всех типов хранилищ булевая настройка отлупа при переписывании тайла поверх тайлом другого размера. Для версионных будет работать по версиям (не в смысле для каждой версии своя, а вообще одна на хранилище, хотя если версии целочисленные и настройка не булевая а типа число - можно подумать над ней как границей версий). Для неверсионных будет аналог блокировки перезаписи тайлов в хранилище. В общем разумное применение можно для всех типов кэша найти, кроме GE и GC. Но опять же это не чисто берклиевская фича.

(0011101) Papazol (reporter) 16-04-2013 13:12	Протестировал сборку. Есть замечания. 1. При выборе папки, куда копировать кэш, отсутствует возможность создать папку, её приходится создавать сторонними средствами. 2. При копировании внутри выбранной папки создаётся папка с названием копируемой, это лишнее. 3. Если при выборе версии ввести слово, например, Google, то копирование происходит, но посмотреть ничего невозможно, так как с списке версий такого слова нет. Если слова недопустимы, то программа должна как-то сообщить об этом, прежде чем копировать. 4. Если скопировать сначала снимок с одним zmp, а потом ещё один уже с другим zmp, изменив версию, то создадутся две папки со своими базами, которые нельзя объединить. 5. Если скопировать в разные версии несколько снимков одного zmp, то копирование происходит, но в списке доступных версий будет только самая первая. Но, включив режим Show Previous Version, можно увидеть всё скопированное.

(0011102) zed (manager) 16-04-2013 13:43	Всё, что вы описали, кроме п.3,5 - обычное поведение САСа из вкладки Скопировать. Версии тут совершенно ни при чём. А тем более Беркли. По п.3 посмотрю, что там не так со строковыми версиями. По п.5 не совсем понятно. Снимки накладываются друг на друга? Ведь список версий строится только для конкретной точки, куда вы кликнули мышью. Если снимки не перекрывают друг друга, то никакого списка версий вы и не увидите. Это нормальное поведение и потому придумана галочка Show Previous Version.

(0011103) Garl (manager) 16-04-2013 13:56	>По п.5 а может можно выводить версии для текущей отображаемой площади?

(0011104) zed (manager) 16-04-2013 13:57	>а может можно выводить версии для текущей отображаемой площади? Может и можно, но не в этом тикете.

(0011107) Papazol (reporter) 16-04-2013 16:38 edited on: 16-04-2013 16:40	По пунктам. 1. Это просто неудобство, можно было бы ввести создание папки во все операции копирования. 2. Приведу пример для ясности. Беру кэш Гугля и выделяю один снимок, обведённый полигоном. Задаю скопировать его в версионный кэш под версией 001. Папка версионного кэша создана заранее и называется Test_Version. Для неё создан zmp, в котором указано NameInCache=Test_Version. При копировании выделенной области в папке Test_Version создаётся ещё одна папка с названием Google_sat, потому что копирование идёт из неё. Когда копирование завершается, я не могу посмотреть новый кэш, потому что в папке, указанной как NameInCache, ничего нет. Приходится перемещать содержимое вложенной папки Google_sat в папку Test_Version. Тогда можно посмотреть. И что, каждый раз перемещать всю папку? 4. Опять же на примере. Беру некоторую область на снимках Гугля. Копирую её в версионный кэш под версией 001. Следующим шагом беру снимки Bing Maps и копирую в версионный же кэш под версией 002. Эти снимки конкретно перекрываются. Логично предположить, что при просмотре версионного кэша можно будет выбрать снимки Гугля, установив версию 001, либо снимки Бинга, установив версию 002. Но нет, снимки гугля помещаются в папку Google_sat, а снимки Бинга - в папку Bing_sat. Это по сути две разные базы. Получается, чтобы эти снимки поместить в один версионный кэш, нужно после копирования Гугля переименовать Бинг в Гугль, и тогда создастся полноценная версия 002. 5. И снова пример. Беру на снимках Гугля один снимок, обведённый полигоном. Копирую его в версионный кэш под версией 001. Беру оттуда же другой снимок, обведённый другим полигоном и копирую в тот же версионный кэш под версией 002. Замечу, что исходный кэш обычный, поэтому снимки не могут перекрываться физически. Папка с новым кэшем в этом случае одна, вроде бы всё хорошо. Но выбрать для просмотра версию 002 невозможно. Но она же там есть! И даже её можно посмотреть, но только вместе со снимками версии 001. И по логике, если я копирну в версию 002 хотя бы один тайл, перекрывающийся с версией 001, то в списке версий появится 002 и я смогу просмотреть его целиком? Наверно, я не совсем понимаю всей задумки, странно только, что все остальные её понимают, раз вопросы у одного меня. PS Может, оффтоп, но некоторые кэши данная сборка не открывает, хотя ночнушка - запросто. Всё Беркли. Прикладываю эльф.

(0011108) zed (manager) 16-04-2013 16:48	По п.5 посмотрите демку: http://yadi.sk/d/GKlV5VmX45WjK Повторяю ещё раз (вы мои сообщениия читаете?) если снимки не перекрываются, то в списке версий нечего выводить. Про остальное (п.п. 1,2,4) было понятно и из прошлого сообщения. Не нравится - открывайте хотелку и т.д. и т.п. К версионности в Беркли и данному тикету это всё не имеет никакого отношения. Вы описали нормальное поведение при копировании, которое существует в САС уже испокон веков.

(0011109) zed (manager) 16-04-2013 17:39	Влил изменения в основную ветку, так что завтра можно будет щупать ночнушку. Версионный Беркли идёт отдельным типом кэша, но он умеет читать/писать в неверсионный кэш и дефолтные папки для версионного и обычного Беркли совпадают.

(0011115) Papazol (reporter) 17-04-2013 06:39	>Повторяю ещё раз (вы мои сообщениия читаете?)< Конечно, читаю, но содержащейся в них информации мне не хватает. Пока не посмотрел видео, ну никак не врубился, что было задумано. И всё равно вопросы и предложения. Можно ли как-нибудь принудительно назначить существующему кэшу версию? А то получается, что этот существующий кэш без версии, поэтому его тайлы могут быть заменены на тайлы любой версии. И проверка CRC здесь не работает. Копировать весь кэш в другое хранилище не совсем наш метод. При скачивании тайла, который совпадает с уже существующим, тайл не сохраняется, но счётчик его считает. И никакого сообщения не выдаётся, что, мол, тайл не сохранён, потому что и т. д. Бывают такие тайлы, изображение у которых отличается от старого/нового одним-двумя пикселями. То есть, на глаз отличий не заметно. И становится непонятно, скачался (читай: сохранился) этот тайл или нет.

(0011116) zed (manager) 17-04-2013 07:08	>Можно ли как-нибудь принудительно назначить существующему кэшу версию? Когда у меня дойдут руки до вкладки управление кэшем, можно будет импортировать весь неверсионный кэш в версионный, с указанием любой версии. Т.е. как на вкладке Скопировать, только для всего кэша целиком и без создания дополнительных подпапок. >А то получается, что этот существующий кэш без версии, поэтому его тайлы могут быть заменены на тайлы любой версии. И проверка CRC здесь не работает. Не могут. Неверсионные тайлы сами по себе и версионные их никак не перезаписывают. >При скачивании тайла, который совпадает с уже существующим, тайл не сохраняется, но счётчик его считает. Если речь про скачивание тойже самой версии, то да, я отключил в кэше перезапись тайлов с одинаковой версией. Пока что никаких сообщений не выводится, т.к. тут нужны глобальные изменение в САС, а не именно в Беркли. Зато теперь в режиме Интернет вы ничего случайно не перезапишите. А если таки нужно перезаписать, то вначале придётся вручную удалить ненужные тайлы, а потом уже записывать.

(0011117) Papazol (reporter) 17-04-2013 07:39 edited on: 17-04-2013 07:42	>Неверсионные тайлы сами по себе и версионные их никак не перезаписывают.< То есть, тайлы дублируются. Очень нужна операция перевода неверсионного кэша в версионный. Ещё из обнаруженного. Вот сейчас пытаюсь собрать три версии Гугля. Пока доступны. Выделил область, закачал пока только на z14 три версии. Хочу посмотреть, где в какой версии есть тайлы. Но на z9 версию выбрать нельзя, значит, и карту заполнения для версии построить тоже нельзя. Скачивать три версии z9 смысла нет, потому что на этом уровне для всех версий одно и то же. У меня там изображение, сформированное из z14, чтобы видеть, где есть снимки. Кстати, будет работать формирование другого уровня из выбранной версии? И ещё вопрос. Если случайно нажать в меню пункт "Сбросить", что будет? Не приведёт это к необратимым последствиям, в смысле всё заново перекачивать?

(0011118) zed (manager) 17-04-2013 07:44 edited on: 17-04-2013 07:50	>карту заполнения для версии построить тоже нельзя Можно. Для текущей версии, которая указана в параметрах карты. Но нужно отключить Show Prev. Version. >Кстати, будет работать формирование другого уровня из выбранной версии? Должно. Но не проверял. >Если случайно нажать в меню пункт "Сбросить", что будет? Не приведёт это к необратимым последствиям, в смысле всё заново перекачивать? Это всего лишь очищает значение Версия в параметрах карты. Или можно сказать, что это включает неверсионный режим.

(0011119) Papazol (reporter) 17-04-2013 08:02	Сформировать другой уровень можно. Формирует в версию, из которой берёт исходник, т. е. которая указана в параметрах карты. Но попутно захватывает и неверсионную часть кэша. Как бы её... Хорошо бы видимый индикатор текущей версии, а то каждый раз лазить в параметры карты приходится.

(0011120) zed (manager) 17-04-2013 08:07	>Но попутно захватывает и неверсионную часть кэша. Не должно бы. А Show Previous Version отключено?

(0011121) Papazol (reporter) 17-04-2013 08:15	Да, отключено. И карта заполнения тоже неверсионную часть показывает. Вообще странные штуки с этими версиями. Похоже, что некоторые тайлы в разных версиях одинаковы. Из-за этого на снимках образуются дырки.

(0011122) zed (manager) 17-04-2013 08:16	>Да, отключено. И карта заполнения тоже неверсионную часть показывает. О, значит буду лечить.

(0011123) Papazol (reporter) 17-04-2013 08:22 edited on: 17-04-2013 18:07	Но самое плохое, что если сделать удаление выделенной области, то вместе с версией, указанной в параметрах карты, удаляется и неверсионная часть кэша. Я уже удалил :) UPD Странно, но здесь что-то не так. Вывод об удалении неверсионной части кэша я сделал на основе карты заполнения. Было пустое место. А в следующий запуск программы тайлы появились. Может, я чего попутал. А вот при попытке удалить по ЛКМ+Del тайл, отсутствующий в заданной версии, но существующий в неверсионной части кэша, программа виснет. Если отменить версионность, то удаляется нормально.

(0011135) zed (manager) 17-04-2013 20:10 edited on: 17-04-2013 21:09	Проверяйте завтра - кое-что поправил, касательно неверсионных тайлов. И багу с зависанием отловил.

(0011137) Garl (manager) 18-04-2013 04:39	теперь бы и версионные .tne :)

(0011138) zed (manager) 18-04-2013 05:31	Так уже.

(0011139) Garl (manager) 18-04-2013 06:06	так а чего тогда они не отображаются красным?

(0011141) Papazol (reporter) 18-04-2013 13:37 edited on: 18-04-2013 13:39	После доработок программа не видит ранее созданные версии. Более того, и создать версии по-новой не могу.

(0011142) Garl (manager) 18-04-2013 13:39	зато переписав раннее созданные тайлы - всё пока работает как надо по логике. единственное что хочется - это проверять версии нижележащих тайлов

(0011143) Papazol (reporter) 18-04-2013 13:47	Как это - переписав? Я пробовал сделать всё с нуля: новая папка, новый zmp, по-новой скачать. Скачав версию 125, исправил на 126 и попытался скачать снова. Так фигвам: Этот тайл уже имеется в кэше. Где версионность? В меню исчез пункт Показать предыдущие версии. Так задумано?

(0011144) zed (manager) 18-04-2013 13:48	>В меню исчез пункт Показать предыдущие версии. Так задумано? А тип кэша BerkeleyDB (Versioned)?

(0011145) Garl (manager) 18-04-2013 13:49 edited on: 18-04-2013 13:52	кстати тип кэша в ini = 61 так и надо? а почему не следующий по подярку?

(0011146) Papazol (reporter) 18-04-2013 13:58	>А тип кэша BerkeleyDB (Versioned)?< Гы, конечно, нет! Теперь номер версии, указанный в zmp, применяется к существующему неверсионному кэшу?

(0011148) zed (manager) 18-04-2013 14:34	>а почему не следующий по подярку? Вполне себе по порядку. Просто Беркли - 6, с версией - 61. А кэш с номером 7 уже застолблён - СУБД. Поэтому только так. >Теперь номер версии, указанный в zmp, применяется к существующему неверсионному кэшу? Что значит применяется? В Беркли версия тайлов сохранялась с самого первого релиза. Правда он там была никак не задействована и носила чисто информативный характер.

(0011149) Papazol (reporter) 18-04-2013 15:08	Копировать кэш из одного хранилища в другое с указанием версии не получается опять из-за создания новой папки с названием кэша-источника. Пока адекватно работает только скачивание в чистый версионный кэш.

(0011152) zed (manager) 19-04-2013 04:27	>из-за создания новой папки с названием кэша-источника Можно предварительно создать эту папку и переместить в неё весь кэш из другой папки. Не удобно, но сработает.

(0011153) Papazol (reporter) 19-04-2013 04:46	Надо сделать качественный скачок. Копирование обязано работать так, как надо. И индикацию текущей версии видимую, в статусной строке или типа того.

(0011154) zed (manager) 19-04-2013 04:53	Я уже говорил - пишите хотелки.

(0011155) vdemidov (manager) 19-04-2013 04:53	Заводите хотелки

(0011669) zed (manager) 15-06-2013 16:06	Поскольку сохранить полную совместимость всё-равно не получилось - версионный кэш идёт отдельным типом, то сделал его полностью самостоятельным, со своей папкой в кэше (cache_dbv) и своим расширением файлов БД (sdbv и tnev). Так же, в этом кэше тайлы без версии будут сохраняться аналогично версионным, со всеми вытекающими последствиями.

Users who viewed this issue
User List	Anonymous (4723x), kurt23 (2x)
Total Views	4725
Last View	21-11-2024 17:32

Issue History
Date Modified	Username	Field	Change
31-03-2013 09:34	zed	New Issue
31-03-2013 09:34	zed	Status	new => assigned
31-03-2013 09:34	zed	Assigned To	=> zed
31-03-2013 10:03	vasketsov	Note Added: 0010950
31-03-2013 10:41	zed	Note Added: 0010951
31-03-2013 11:57	vdemidov	Note Added: 0010952
31-03-2013 12:03	zed	Note Added: 0010953
31-03-2013 13:21	zed	Note Added: 0010954
31-03-2013 17:46	zed	Note Added: 0010956
07-04-2013 12:21	zed	Note Added: 0011036
14-04-2013 05:41	Papazol	Note Added: 0011075
14-04-2013 18:35	zed	Note Added: 0011076
14-04-2013 20:37	Papazol	Note Added: 0011077
14-04-2013 20:38	Papazol	Note Edited: 0011077	View Revisions
14-04-2013 20:45	Papazol	Note Edited: 0011077	View Revisions
15-04-2013 06:23	zed	Note Added: 0011079
15-04-2013 06:28	vasketsov	Note Added: 0011080
15-04-2013 14:16	Papazol	Note Added: 0011087
15-04-2013 16:31	zed	Note Added: 0011088
15-04-2013 17:50	vasketsov	Note Added: 0011089
15-04-2013 19:19	zed	Note Added: 0011092
15-04-2013 19:56	vdemidov	Note Added: 0011093
15-04-2013 20:06	zed	Note Added: 0011094
16-04-2013 04:42	Papazol	Note Added: 0011098
16-04-2013 07:08	zed	Note Added: 0011099
16-04-2013 08:01	vasketsov	Note Added: 0011100
16-04-2013 13:12	Papazol	Note Added: 0011101
16-04-2013 13:43	zed	Note Added: 0011102
16-04-2013 13:56	Garl	Note Added: 0011103
16-04-2013 13:57	zed	Note Added: 0011104
16-04-2013 16:38	Papazol	File Added: SASPlanet.MultiVersions.BerkeleyDB.elf
16-04-2013 16:38	Papazol	Note Added: 0011107
16-04-2013 16:40	Papazol	Note Edited: 0011107	View Revisions
16-04-2013 16:48	zed	Note Added: 0011108
16-04-2013 17:39	zed	Note Added: 0011109
17-04-2013 06:39	Papazol	Note Added: 0011115
17-04-2013 07:08	zed	Note Added: 0011116
17-04-2013 07:39	Papazol	Note Added: 0011117
17-04-2013 07:42	Papazol	Note Edited: 0011117	View Revisions
17-04-2013 07:44	zed	Note Added: 0011118
17-04-2013 07:50	zed	Note Edited: 0011118	View Revisions
17-04-2013 08:02	Papazol	Note Added: 0011119
17-04-2013 08:07	zed	Note Added: 0011120
17-04-2013 08:15	Papazol	Note Added: 0011121
17-04-2013 08:16	zed	Note Added: 0011122
17-04-2013 08:22	Papazol	Note Added: 0011123
17-04-2013 18:07	Papazol	Note Edited: 0011123	View Revisions
17-04-2013 20:10	zed	Note Added: 0011135
17-04-2013 21:09	zed	Note Edited: 0011135	View Revisions
18-04-2013 04:39	Garl	Note Added: 0011137
18-04-2013 05:31	zed	Note Added: 0011138
18-04-2013 06:06	Garl	Note Added: 0011139
18-04-2013 13:37	Papazol	Note Added: 0011141
18-04-2013 13:39	Papazol	Note Edited: 0011141	View Revisions
18-04-2013 13:39	Garl	Note Added: 0011142
18-04-2013 13:47	Papazol	Note Added: 0011143
18-04-2013 13:48	zed	Note Added: 0011144
18-04-2013 13:49	Garl	Note Added: 0011145
18-04-2013 13:52	Garl	Note Edited: 0011145	View Revisions
18-04-2013 13:58	Papazol	Note Added: 0011146
18-04-2013 14:34	zed	Note Added: 0011148
18-04-2013 15:08	Papazol	Note Added: 0011149
19-04-2013 04:27	zed	Note Added: 0011152
19-04-2013 04:46	Papazol	Note Added: 0011153
19-04-2013 04:53	zed	Note Added: 0011154
19-04-2013 04:53	vdemidov	Note Added: 0011155
10-06-2013 18:42	vasketsov	Relationship added	child of 0001951
10-06-2013 18:42	vasketsov	Relationship deleted	child of 0001951
10-06-2013 18:42	vasketsov	Relationship added	related to 0001951
15-06-2013 16:06	zed	Note Added: 0011669
15-06-2013 16:07	zed	Status	assigned => resolved
15-06-2013 16:07	zed	Fixed in Version	=> 131111
15-06-2013 16:07	zed	Resolution	open => fixed
20-06-2013 06:59	vdemidov	Target Version	24xxxx => 131111

SASGIS