View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001983 | SAS.Планета | Хотелка / Feature request | public | 27-06-2013 15:07 | 22-11-2013 22:22 |
| Reporter | Papazol | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | ||
| Platform | Windows | OS | XP | OS Version | Professional SP3 |
| Product Version | 131111 | ||||
| Target Version | 44xxxx | ||||
| Summary | 0001983: Версионный кэш: переименовать версию | ||||
| Description | В некоторых тайлохранилищах для этого достаточно поменять одну строку в одном месте, но в общем случае это операция для менеджера кэша. | ||||
| Tags | версионный кэш, управление кэшем | ||||
| related to | 0002121 | confirmed | Версионный кэш: удалить версию |
|
|
Что понимается под переименованием версии? Что понимается под удалением версии? |
|
|
Так что конкретно: переименовать или удалить? Один тикет - одна хотелка. |
|
|
1. Переименование - изменение имени (названия) версии. Например, изначально (при создании) версия была названа "Пробная", а затем возникла нужда дать ей имя "Тестовая". 2. Удаление версии - удаление всех тайлов, которые указанная версия содержит, и самого названия этой версии, как будто она не была создана. 3. Операции с версиями - как с файлами/каталогами. Сейчас можно только создать. А нужно и создать, и удалить, и переименовать. Version Commander. Как одно от другого отделить? Давайте назовём это операциями с версиями? |
|
|
Так операция Удалить с выделенной областью прекрасно решает задачу удаления. Главное иметь ввиду 0001965 и не переключать версии, пока операция не завершится. А по поводу "переименования" - есть тикет 0001968 Или хочется проводить все эти операции сразу над всем кэшем, через Управление кэшем? |
|
|
>изменение имени (названия) версии Такое возможно, если версия - самостоятельная сущность. Если же это не так, и версия - лишь атрибут тайла, то каждый тайл версии придётся для этой операции обновить, изменив значение со старой версии на новую. В этом случае это отлично делается прямо сейчас через менеджер кэша (исходное хранилище равно целевому), после того как zed сделал там возможно указания версии для исходного и целевого хранилища. >Удаление версии - удаление всех тайлов, которые указанная версия содержит Есть подозрение, что это проще всего сделать в менеджере кэша, как перенос в дев нулл (ну или в RAM). Хотя это zed-у виднее как автору концепции менеджера кэша. |
|
|
>сразу над всем кэшем, через Управление кэшем? Я понял что "да". |
|
|
>Если же это не так, и версия - лишь атрибут тайла< Это важное замечание, и оно требует либо подтверждения, либо опровержения. Я рассматривал версию как папку, содержащую файлы. Если всё не так, то дело в корне меняется. Получается так, что, если нет ни одного тайла, числящегося под этой версией, то и самОй версии нет? И всё же, интуитивно понятный инструмент должен быть. Хотя бы для переименования. Не каждый догадается подставить одно и то же как источник и цель. |
|
|
>Если всё не так, то дело в корне меняется Всё не так. Версия, это свойство файла, такое же как, к примеру, дата создания тайла. |
|
|
Ну вот, когда знаешь устройство, глупые мысли реже возникают. Закрываем? |
|
|
Изменить версию через Управление кэшем сейчас не получится. Сработает защита по CRC. Да и удалить версию всему кэшу сейчас тоже нельзя - только через выделенную область. Так что по-моему хотелку нужно переименовать и разбить на задачи переименования и удаления, а так же конкретизировать, как это делать - через выделенную область или через Управление кэшем. |
|
|
>Изменить версию через Управление кэшем сейчас не получится. Сработает защита по CRC.< У меня не получилось сделать это и через выделенную область. Хотел перекинуть один снимок из общей кучи в отдельную версию. И всё вроде сработало, ни ошибок, ни предупреждений. А версии той, что я указал, просто не появилось. Тайлы ушли в никуда. Если для переименования версии потребуется столько же времени, сколько для копирования, лучше уж пускай остаётся старая. С удалением всё попроще, как я понял. Удаляем тайлы любым способом, и версия пропадает. |
|
|
>У меня не получилось сделать это и через выделенную область. Ну так да. Никак не получится. >Если для переименования версии потребуется столько же времени, сколько для копирования Если сделать это отдельной операцией, то меньше, но всё упирается в 0001968 |
|
|
>Ну так да. Никак не получится.< С этим надо что-то делать. Блокировку что ли от перемещения тайлов внутри одного кэша. Иначе легко потерять много инфы. |
|
|
>Блокировку что ли от перемещения тайлов внутри одного кэша Нельзя. Защита по CRC - фича исключительно беркли. Тогда уж надо наоборот отключать проверку CRC, если юзер заставляет программу переносить тайлы внутри одного кэша, заодно и галочку сделать типа Same as Source в менеджере кэша, по которой серить настройку (путь+тип) целевого кэша (точнее даже получается 3 варианта: 1 - такой же как источник, 2 - определённый руками, 3 - RAM для выпиливания определённой версии из всего исходного кэша). |
|
|
>Защита по CRC - фича исключительно беркли. В СУБД же есть аналогичная защита, только там идентичность тайлов проверяется по их размеру. Или опция DontKeepIfSameAsPrevVersion это что-то другое? |
|
|
Это проверка только относительно одной предыдущей версии исходя из алгоритма сравнимости версий (в SQlite и файловом при VersionInCache тоже реализовано, но без настраиваемого алгоритма сравнимости, то есть у яндекса 3.102<3.99 будет везде, и только для СУБД можно сделать правильно). Используется для проверки наличия обновления покрытия. |
|
|
Не вдаваясь в глубокие подробности строения, я понимаю проблему следующим образом: программа берёт очередной тайл из исходного кэша, зная его тайловые координаты, проходится по базе в поисках тайла с такими же тайловыми координатами. И находит этот же тайл. Раз он существует, то "новый" тайл сохранять не нужно, а вот старый нужно удалить, ведь было задано перемещение. Если несколько изменить последовательность операций, то проблема может решиться. Нужно перед поиском существующих тайлов удалить тайл-источник, тогда программа с чистой совестью сохранит новый тайл под нужной версией. А вот копирование из кэша в него же смысла не имеет совсем. |
|
|
Удалять что, не убедившись сперва что это что-то записалось куда надо, не очень хорошая идея. |
|
|
>Нужно перед поиском существующих тайлов удалить тайл-источник И в случае краха тайл будет потерян отовсюду ((( >копирование из кэша в него же смысла не имеет совсем Ещё как имеет, именно при этой операции можно заменить версию у тайла. На примере изменения версии "Пробная" на версию "Тестовая" картина следующая. Сейчас при переносе в тот же кэш (кроме кэша типа беркли): 1. Берётся тайл версии "Пробная". 2. Сохраняется как тайл версии "Тестовая". 3. Удаляется тайл версии "Пробная". В беркли на шаге 2 происходит облом по CRC. Если в менеджер кэша явно передать признак, что это тот же самый кэш, то возможно будет прямо изменить версию у тайла. Если не передать признак - надо отключить проверку на шаге 2, но тогда это будет сильно медленнее по скорости. |
|
|
>то возможно будет прямо изменить версию у тайла Этот "флаг" нужно как-то передать в хранилище, но vdemidov почему-то сильно против того, чтобы я изменял интерфейс хранилища, добавляя туда нужные методы 0001968:0011727 Поэтому, если кому-то сильно приспичит изменять версию, нужно будет экспортировать эти тайлы в другой кэш, удалять их из текущего, а затем уже импортировать под новой версией. |
|
|
>vdemidov почему-то сильно против Вообще-то vdemidov был против z-order для версий потайлово. Проца типа SetTileVersion(xy, zoom, old_version, new_version, remove_old_if_new_version_exists_flags) представляется вполне безобидной, понятной, нужной и несложной. |
|
|
>Вообще-то vdemidov был против z-order для версий потайлово. Я понял его совсем иначе. И процедуру я предлагал общую, чтобы через неё можно было изменять вообще любое свойство тайла, а не конкретно версию или z-order. Т.е. в качестве параметра передавать какой-то общий интерфейс, а уже внутри смотреть, какое конкретно свойство тайла просят поменять. |
|
|
>процедуру я предлагал общую Смысла не вижу в одной общей. Это только усложнит реализацию и привнесёт лишние тормоза. Ну будет внутри неё новый switch по этому интерфейсу-параметру, где выиграем-то? Что нет лишней процедуры SetTileVersion в интерфейсе? Да пофигу сколько их, пока меньше чем 255, на скорости работы это не скажется. |
|
|
>какое конкретно свойство тайла просят поменять А какие свойства тайла можно менять в приниципе? Тело (nil для TNE). Версию. И всё (в предположении отказа от z-order)? |
|
|
Да смысл не в том, какая там будет процедура, а в том, что было сказано "Только не меняй интерфейс тайлохранилища". И этим всё сказано. |
|
|
Разве этим было всё сказано, если дальше было "то можно"? Товарищ же прямо написал, что считает достаточным (а следовательно допустимым) z-order для версий. А как его реализовать без внесения изменений в хранилище - ума не приложу ))). Так что я понял его именно в контексте избыточности потайлового z-order-а. |
|
|
>Товарищ же прямо написал Ну да, прямо написал - переделай весь существующий интерфейс, унифицируй методы Save/SaveTne/Del, перелопать 100500 строк кода, а потом можешь и свою хотелку там сбоку реализовать. Это я считаю маразмом и пускай он сам это реализует хоть в 20-м году. >Так что я понял его именно в контексте избыточности потайлового z-order-а. Да его фиг поймёшь. Но баба с возу - кобыле легче. Я теперь на любые вопросы "как поменять версию у тайлов", буду отправлять в тот тикет - пускай ждут. |
|
|
>Это я считаю маразмом Угу. Но я всё же сделаю у себя процу типа SetTileVersion, заодно разберёмся с тем, какие ей флаги надо передавать в общем случае, для каких хранилищ она будет актуальна (например для файлового это будет простой перенос тайла между папками, а вот для СУБД будет в общем случае сложнее), и т.п. А там уж поглядим, может передумает. |
|
|
>"как поменять версию у тайлов", буду отправлять в тот тикет - пускай ждут. ну так экспорт в файловый кэш и загрузка обратно в версионный с принудительной установкой версии... у мну был даже не глюк а фича (проверка CRC): были тайлы с неверной версией, и я никак не мог записать точно такой же тайл в эти же координаты, но с другой (правильной) версией, можно сделать хоть какую-либо индикацию? |
|
|
Vasketsov меня понял абсолютно правильно — я против добавления z-order для каждого тайла. А про >переделай весь существующий интерфейс, унифицируй методы Save/SaveTne/Del, перелопать 100500 строк кода, а потом можешь и свою хотелку там сбоку реализовать Я имел в виду, что если хочешь сделать универсальный метод — то незачем оставлять частные. Или один общий или несколько специализированных. А 100500 строк кода — ну что поделаешь. А ты ты сразу без слов закрыл тикет и все. |
|
|
>Я имел в виду, что если хочешь сделать универсальный метод Я хотел сделать универсальную функцию изменения свойств тайл. Ты ответил, что можно, но только если я переделаю все остальные функции. И сейчас это подтверждаешь. Так в чём вопрос. Как я тебя неправильно понял? |
|
|
если хочешь сделать универсальный метод — то незачем оставлять частные. Или один общий или несколько специализированных |
|
|
Значит надо было так и написать. Я не телепат. А теперь я уже вообще ничего не хочу. Ни частных методов, ни универсальных. Спасибо. |
|
|
>И в случае краха тайл будет потерян отовсюду (((< Сейчас даже без краха тайл теряется, причём безвозвратно. Никакой защиты от этого, кроме самого пользователя, нет. Всё происходит так же, как и при закачке. Только вот при закачке тайл всё-таки остаётся на сервере. |
|
|
>Сейчас даже без краха тайл теряется, причём безвозвратно Не понял. Каким образом? |
|
|
Таким: >программа берёт очередной тайл из исходного кэша, зная его тайловые координаты, проходится по базе в поисках тайла с такими же тайловыми координатами. И находит этот же тайл. Раз он существует, то "новый" тайл сохранять не нужно, а вот старый нужно удалить, ведь было задано перемещение< И всё вроде "по закону", а данные исчезают. |
|
|
>>Сейчас даже без краха тайл теряется, причём безвозвратно >Не понял. Каким образом? Смотри TThreadCacheConverter.Process. Выход на FSourceRemoveTiles не зависит от того, был ли реально сохранён тайл в целевом хранилище. зы. Я щас у себя сделаю флаг в виде переменной out, в неё и буду пихать результат SaveTile, тогда полечится. ззы. Считаю, что нельзя удалять тайл, если он не записался. ззы. Хм. А если указана версия, а она не та, тайл тоже удалится? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 27-06-2013 15:07 | Papazol | New Issue | |
| 27-06-2013 15:10 | vasketsov | Note Added: 0011820 | |
| 27-06-2013 15:12 | zed | Note Added: 0011821 | |
| 27-06-2013 15:13 | zed | Note Edited: 0011821 | |
| 27-06-2013 15:25 | Papazol | Note Added: 0011823 | |
| 27-06-2013 15:36 | zed | Note Added: 0011824 | |
| 27-06-2013 15:39 | vasketsov | Note Added: 0011825 | |
| 27-06-2013 15:40 | vasketsov | Note Added: 0011827 | |
| 27-06-2013 15:44 | Papazol | Note Added: 0011830 | |
| 27-06-2013 15:48 | Papazol | Note Edited: 0011830 | |
| 27-06-2013 15:49 | Papazol | Note Edited: 0011830 | |
| 27-06-2013 15:55 | Papazol | Note Edited: 0011830 | |
| 27-06-2013 15:56 | zed | Note Added: 0011832 | |
| 27-06-2013 16:05 | Papazol | Note Added: 0011837 | |
| 27-06-2013 16:15 | zed | Note Added: 0011838 | |
| 27-06-2013 16:27 | Papazol | Note Added: 0011839 | |
| 27-06-2013 16:30 | zed | Note Added: 0011840 | |
| 27-06-2013 20:19 | Papazol | Note Added: 0011852 | |
| 27-06-2013 21:18 | vasketsov | Note Added: 0011853 | |
| 27-06-2013 21:22 | vasketsov | Note Edited: 0011853 | |
| 27-06-2013 21:32 | zed | Note Added: 0011854 | |
| 27-06-2013 21:44 | vasketsov | Note Added: 0011855 | |
| 27-06-2013 21:46 | Papazol | Note Added: 0011856 | |
| 27-06-2013 21:49 | zed | Note Added: 0011857 | |
| 27-06-2013 21:56 | vasketsov | Note Added: 0011858 | |
| 27-06-2013 22:04 | zed | Note Added: 0011859 | |
| 27-06-2013 22:09 | vasketsov | Note Added: 0011860 | |
| 27-06-2013 22:15 | zed | Note Added: 0011861 | |
| 27-06-2013 22:23 | vasketsov | Note Added: 0011862 | |
| 27-06-2013 22:26 | vasketsov | Note Added: 0011863 | |
| 27-06-2013 22:27 | zed | Note Added: 0011864 | |
| 27-06-2013 22:30 | vasketsov | Note Added: 0011865 | |
| 27-06-2013 22:37 | zed | Note Added: 0011866 | |
| 27-06-2013 22:42 | zed | Note Edited: 0011866 | |
| 27-06-2013 22:42 | vasketsov | Note Added: 0011867 | |
| 28-06-2013 04:04 | Garl | Note Added: 0011869 | |
| 28-06-2013 04:04 | Garl | Note Edited: 0011869 | |
| 28-06-2013 08:49 | vdemidov | Note Added: 0011880 | |
| 28-06-2013 08:55 | zed | Note Added: 0011881 | |
| 28-06-2013 09:02 | vdemidov | Note Added: 0011882 | |
| 28-06-2013 09:08 | zed | Note Added: 0011883 | |
| 28-06-2013 10:36 | Papazol | Note Added: 0011889 | |
| 28-06-2013 10:39 | zed | Note Added: 0011893 | |
| 01-07-2013 20:55 | Papazol | Note Added: 0011965 | |
| 02-07-2013 11:55 | vasketsov | Note Added: 0011990 | |
| 02-07-2013 11:57 | vasketsov | Note Edited: 0011990 | |
| 02-07-2013 12:01 | vasketsov | Note Edited: 0011990 | |
| 02-07-2013 12:03 | vasketsov | Note Edited: 0011990 | |
| 28-08-2013 08:25 | vdemidov | Summary | Версионный кэш Беркли: переименовать и удалить версию => Версионный кэш: переименовать и удалить версию |
| 28-08-2013 08:26 | vdemidov | Issue cloned: 0002121 | |
| 28-08-2013 08:26 | vdemidov | Relationship added | related to 0002121 |
| 28-08-2013 08:28 | vdemidov | Summary | Версионный кэш: переименовать и удалить версию => Версионный кэш: переименовать версию |
| 28-08-2013 08:28 | vdemidov | Description Updated | |
| 28-08-2013 08:28 | vdemidov | Status | new => confirmed |
| 28-08-2013 08:28 | vdemidov | Target Version | => 44xxxx |
| 28-08-2013 08:31 | vdemidov | Tag Attached: версионный кэш | |
| 28-08-2013 09:19 | vdemidov | Tag Attached: управление кэшем | |
| 22-11-2013 22:22 | vdemidov | Product Version | .Nightly => 131111 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |