|
Notes |
|
|
|
Что понимается под переименованием версии?
Что понимается под удалением версии? |
|
|
|
(0011821)
|
|
zed
|
27-06-2013 15:12
(edited on: 27-06-2013 15:13) |
|
Так что конкретно: переименовать или удалить? Один тикет - одна хотелка.
|
|
|
|
|
1. Переименование - изменение имени (названия) версии. Например, изначально (при создании) версия была названа "Пробная", а затем возникла нужда дать ей имя "Тестовая".
2. Удаление версии - удаление всех тайлов, которые указанная версия содержит, и самого названия этой версии, как будто она не была создана.
3. Операции с версиями - как с файлами/каталогами. Сейчас можно только создать. А нужно и создать, и удалить, и переименовать. Version Commander. Как одно от другого отделить? Давайте назовём это операциями с версиями? |
|
|
|
(0011824)
|
|
zed
|
|
27-06-2013 15:36
|
|
Так операция Удалить с выделенной областью прекрасно решает задачу удаления. Главное иметь ввиду 0001965 и не переключать версии, пока операция не завершится.
А по поводу "переименования" - есть тикет 0001968
Или хочется проводить все эти операции сразу над всем кэшем, через Управление кэшем? |
|
|
|
|
>изменение имени (названия) версии
Такое возможно, если версия - самостоятельная сущность.
Если же это не так, и версия - лишь атрибут тайла, то каждый тайл версии придётся для этой операции обновить, изменив значение со старой версии на новую.
В этом случае это отлично делается прямо сейчас через менеджер кэша (исходное хранилище равно целевому), после того как zed сделал там возможно указания версии для исходного и целевого хранилища.
>Удаление версии - удаление всех тайлов, которые указанная версия содержит
Есть подозрение, что это проще всего сделать в менеджере кэша, как перенос в дев нулл (ну или в RAM). Хотя это zed-у виднее как автору концепции менеджера кэша. |
|
|
|
|
>сразу над всем кэшем, через Управление кэшем?
Я понял что "да". |
|
|
|
(0011830)
|
|
Papazol
|
27-06-2013 15:44
(edited on: 27-06-2013 15:55) |
|
>Если же это не так, и версия - лишь атрибут тайла<
Это важное замечание, и оно требует либо подтверждения, либо опровержения. Я рассматривал версию как папку, содержащую файлы. Если всё не так, то дело в корне меняется. Получается так, что, если нет ни одного тайла, числящегося под этой версией, то и самОй версии нет?
И всё же, интуитивно понятный инструмент должен быть. Хотя бы для переименования. Не каждый догадается подставить одно и то же как источник и цель.
|
|
|
|
(0011832)
|
|
zed
|
|
27-06-2013 15:56
|
|
>Если всё не так, то дело в корне меняется
Всё не так. Версия, это свойство файла, такое же как, к примеру, дата создания тайла. |
|
|
|
|
|
Ну вот, когда знаешь устройство, глупые мысли реже возникают. Закрываем? |
|
|
|
(0011838)
|
|
zed
|
|
27-06-2013 16:15
|
|
|
Изменить версию через Управление кэшем сейчас не получится. Сработает защита по CRC. Да и удалить версию всему кэшу сейчас тоже нельзя - только через выделенную область. Так что по-моему хотелку нужно переименовать и разбить на задачи переименования и удаления, а так же конкретизировать, как это делать - через выделенную область или через Управление кэшем. |
|
|
|
|
>Изменить версию через Управление кэшем сейчас не получится. Сработает защита по CRC.<
У меня не получилось сделать это и через выделенную область. Хотел перекинуть один снимок из общей кучи в отдельную версию. И всё вроде сработало, ни ошибок, ни предупреждений. А версии той, что я указал, просто не появилось. Тайлы ушли в никуда.
Если для переименования версии потребуется столько же времени, сколько для копирования, лучше уж пускай остаётся старая.
С удалением всё попроще, как я понял. Удаляем тайлы любым способом, и версия пропадает. |
|
|
|
(0011840)
|
|
zed
|
|
27-06-2013 16:30
|
|
>У меня не получилось сделать это и через выделенную область.
Ну так да. Никак не получится.
>Если для переименования версии потребуется столько же времени, сколько для копирования
Если сделать это отдельной операцией, то меньше, но всё упирается в 0001968 |
|
|
|
|
>Ну так да. Никак не получится.<
С этим надо что-то делать. Блокировку что ли от перемещения тайлов внутри одного кэша. Иначе легко потерять много инфы. |
|
|
|
(0011853)
|
|
vasketsov
|
27-06-2013 21:18
(edited on: 27-06-2013 21:22) |
|
>Блокировку что ли от перемещения тайлов внутри одного кэша
Нельзя. Защита по CRC - фича исключительно беркли.
Тогда уж надо наоборот отключать проверку CRC, если юзер заставляет программу переносить тайлы внутри одного кэша, заодно и галочку сделать типа Same as Source в менеджере кэша, по которой серить настройку (путь+тип) целевого кэша (точнее даже получается 3 варианта: 1 - такой же как источник, 2 - определённый руками, 3 - RAM для выпиливания определённой версии из всего исходного кэша).
|
|
|
|
(0011854)
|
|
zed
|
|
27-06-2013 21:32
|
|
>Защита по CRC - фича исключительно беркли.
В СУБД же есть аналогичная защита, только там идентичность тайлов проверяется по их размеру. Или опция DontKeepIfSameAsPrevVersion это что-то другое? |
|
|
|
|
Это проверка только относительно одной предыдущей версии исходя из алгоритма сравнимости версий (в SQlite и файловом при VersionInCache тоже реализовано, но без настраиваемого алгоритма сравнимости, то есть у яндекса 3.102<3.99 будет везде, и только для СУБД можно сделать правильно).
Используется для проверки наличия обновления покрытия. |
|
|
|
|
Не вдаваясь в глубокие подробности строения, я понимаю проблему следующим образом: программа берёт очередной тайл из исходного кэша, зная его тайловые координаты, проходится по базе в поисках тайла с такими же тайловыми координатами. И находит этот же тайл. Раз он существует, то "новый" тайл сохранять не нужно, а вот старый нужно удалить, ведь было задано перемещение.
Если несколько изменить последовательность операций, то проблема может решиться. Нужно перед поиском существующих тайлов удалить тайл-источник, тогда программа с чистой совестью сохранит новый тайл под нужной версией.
А вот копирование из кэша в него же смысла не имеет совсем. |
|
|
|
(0011857)
|
|
zed
|
|
27-06-2013 21:49
|
|
|
Удалять что, не убедившись сперва что это что-то записалось куда надо, не очень хорошая идея. |
|
|
|
|
>Нужно перед поиском существующих тайлов удалить тайл-источник
И в случае краха тайл будет потерян отовсюду (((
>копирование из кэша в него же смысла не имеет совсем
Ещё как имеет, именно при этой операции можно заменить версию у тайла.
На примере изменения версии "Пробная" на версию "Тестовая" картина следующая.
Сейчас при переносе в тот же кэш (кроме кэша типа беркли):
1. Берётся тайл версии "Пробная".
2. Сохраняется как тайл версии "Тестовая".
3. Удаляется тайл версии "Пробная".
В беркли на шаге 2 происходит облом по CRC.
Если в менеджер кэша явно передать признак, что это тот же самый кэш, то возможно будет прямо изменить версию у тайла. Если не передать признак - надо отключить проверку на шаге 2, но тогда это будет сильно медленнее по скорости. |
|
|
|
(0011859)
|
|
zed
|
|
27-06-2013 22:04
|
|
>то возможно будет прямо изменить версию у тайла
Этот "флаг" нужно как-то передать в хранилище, но vdemidov почему-то сильно против того, чтобы я изменял интерфейс хранилища, добавляя туда нужные методы 0001968:0011727 Поэтому, если кому-то сильно приспичит изменять версию, нужно будет экспортировать эти тайлы в другой кэш, удалять их из текущего, а затем уже импортировать под новой версией. |
|
|
|
|
>vdemidov почему-то сильно против
Вообще-то vdemidov был против z-order для версий потайлово.
Проца типа SetTileVersion(xy, zoom, old_version, new_version, remove_old_if_new_version_exists_flags) представляется вполне безобидной, понятной, нужной и несложной. |
|
|
|
(0011861)
|
|
zed
|
|
27-06-2013 22:15
|
|
>Вообще-то vdemidov был против z-order для версий потайлово.
Я понял его совсем иначе. И процедуру я предлагал общую, чтобы через неё можно было изменять вообще любое свойство тайла, а не конкретно версию или z-order. Т.е. в качестве параметра передавать какой-то общий интерфейс, а уже внутри смотреть, какое конкретно свойство тайла просят поменять. |
|
|
|
|
>процедуру я предлагал общую
Смысла не вижу в одной общей. Это только усложнит реализацию и привнесёт лишние тормоза. Ну будет внутри неё новый switch по этому интерфейсу-параметру, где выиграем-то? Что нет лишней процедуры SetTileVersion в интерфейсе? Да пофигу сколько их, пока меньше чем 255, на скорости работы это не скажется. |
|
|
|
|
>какое конкретно свойство тайла просят поменять
А какие свойства тайла можно менять в приниципе? Тело (nil для TNE). Версию.
И всё (в предположении отказа от z-order)? |
|
|
|
(0011864)
|
|
zed
|
|
27-06-2013 22:27
|
|
|
Да смысл не в том, какая там будет процедура, а в том, что было сказано "Только не меняй интерфейс тайлохранилища". И этим всё сказано. |
|
|
|
|
Разве этим было всё сказано, если дальше было "то можно"?
Товарищ же прямо написал, что считает достаточным (а следовательно допустимым) z-order для версий. А как его реализовать без внесения изменений в хранилище - ума не приложу ))). Так что я понял его именно в контексте избыточности потайлового z-order-а. |
|
|
|
(0011866)
|
|
zed
|
27-06-2013 22:37
(edited on: 27-06-2013 22:42) |
|
>Товарищ же прямо написал
Ну да, прямо написал - переделай весь существующий интерфейс, унифицируй методы Save/SaveTne/Del, перелопать 100500 строк кода, а потом можешь и свою хотелку там сбоку реализовать. Это я считаю маразмом и пускай он сам это реализует хоть в 20-м году.
>Так что я понял его именно в контексте избыточности потайлового z-order-а.
Да его фиг поймёшь. Но баба с возу - кобыле легче. Я теперь на любые вопросы "как поменять версию у тайлов", буду отправлять в тот тикет - пускай ждут.
|
|
|
|
|
>Это я считаю маразмом
Угу.
Но я всё же сделаю у себя процу типа SetTileVersion, заодно разберёмся с тем, какие ей флаги надо передавать в общем случае, для каких хранилищ она будет актуальна (например для файлового это будет простой перенос тайла между папками, а вот для СУБД будет в общем случае сложнее), и т.п. А там уж поглядим, может передумает. |
|
|
|
(0011869)
|
|
Garl
|
|
28-06-2013 04:04
|
|
>"как поменять версию у тайлов", буду отправлять в тот тикет - пускай ждут.
ну так экспорт в файловый кэш и загрузка обратно в версионный с принудительной установкой версии...
у мну был даже не глюк а фича (проверка CRC):
были тайлы с неверной версией, и я никак не мог записать точно такой же тайл в эти же координаты, но с другой (правильной) версией,
можно сделать хоть какую-либо индикацию?
|
|
|
|
|
Vasketsov меня понял абсолютно правильно — я против добавления z-order для каждого тайла. А про
>переделай весь существующий интерфейс, унифицируй методы Save/SaveTne/Del, перелопать 100500 строк кода, а потом можешь и свою хотелку там сбоку реализовать
Я имел в виду, что если хочешь сделать универсальный метод — то незачем оставлять частные. Или один общий или несколько специализированных. А 100500 строк кода — ну что поделаешь. А ты ты сразу без слов закрыл тикет и все. |
|
|
|
(0011881)
|
|
zed
|
|
28-06-2013 08:55
|
|
>Я имел в виду, что если хочешь сделать универсальный метод
Я хотел сделать универсальную функцию изменения свойств тайл. Ты ответил, что можно, но только если я переделаю все остальные функции. И сейчас это подтверждаешь. Так в чём вопрос. Как я тебя неправильно понял? |
|
|
|
|
|
если хочешь сделать универсальный метод — то незачем оставлять частные. Или один общий или несколько специализированных |
|
|
|
(0011883)
|
|
zed
|
|
28-06-2013 09:08
|
|
|
Значит надо было так и написать. Я не телепат. А теперь я уже вообще ничего не хочу. Ни частных методов, ни универсальных. Спасибо. |
|
|
|
|
>И в случае краха тайл будет потерян отовсюду (((<
Сейчас даже без краха тайл теряется, причём безвозвратно. Никакой защиты от этого, кроме самого пользователя, нет. Всё происходит так же, как и при закачке. Только вот при закачке тайл всё-таки остаётся на сервере. |
|
|
|
(0011893)
|
|
zed
|
|
28-06-2013 10:39
|
|
>Сейчас даже без краха тайл теряется, причём безвозвратно
Не понял. Каким образом? |
|
|
|
|
Таким:
>программа берёт очередной тайл из исходного кэша, зная его тайловые координаты, проходится по базе в поисках тайла с такими же тайловыми координатами. И находит этот же тайл. Раз он существует, то "новый" тайл сохранять не нужно, а вот старый нужно удалить, ведь было задано перемещение<
И всё вроде "по закону", а данные исчезают. |
|
|
|
(0011990)
|
|
vasketsov
|
02-07-2013 11:55
(edited on: 02-07-2013 12:03) |
|
>>Сейчас даже без краха тайл теряется, причём безвозвратно
>Не понял. Каким образом?
Смотри TThreadCacheConverter.Process.
Выход на FSourceRemoveTiles не зависит от того, был ли реально сохранён тайл в целевом хранилище.
зы. Я щас у себя сделаю флаг в виде переменной out, в неё и буду пихать результат SaveTile, тогда полечится.
ззы. Считаю, что нельзя удалять тайл, если он не записался.
ззы. Хм. А если указана версия, а она не та, тайл тоже удалится?
|
|