0002090: Разделить версию для закачки от версии для отображения

Notes
(0012393) vasketsov (manager) 14-08-2013 10:59	>Сейчас версия, которая используется в скрипте для загрузки тайлов жестко завязана с версией, которая используется в тайлохранилище для сохранения и отображения тайлов Это не так. Для сохранения используется версия закачки. Для отображения используется Version. Для закачки используется версия, фиксированная на момент закачки: для области выделения - на момент начала операции, для остальных скачек по экрану или по одному тайлу - на момент начала скачк тайла берётся Version.

(0012394) vasketsov (manager) 14-08-2013 11:07	>хочу видеть в качестве вресии в тайлохранилище не "134" которое используется гуглом, а дату ее появления "2013_08_10" Тогда 134 вообще не нужно выделять в виде отдельной версии. Например, можно сделать версию "2013_08_10 (134)" и разбирать её в скрипте. Если отдельно хранить два разных значения для версии 134 и 2013_08_10 в двух разных полях, то придётся их как-то синхронизировать на основании каких-то данных. И если при выходе новой версии ещё понятно, что делать (хотя и негуманно), то в случае необходимости вернуться назад, надо откуда-то брать эту инфу. Гуманно будет указать 2013_08_10 как атрибут версии (дата прилёта). В тайлохранилищах в СУБД можно даже по нему версии сравнивать. Если сделаешь версии вида "2013_08_10 (134)" и разбор в скрипте - будет корректная сортировка (строковая сравнимость yyyy-mm-dd рулит) и корректная работа в любом версионном тайлохранилище.

(0012396) zed (manager) 14-08-2013 11:25	Давай по порядку. Вот у тебя две версии: 1. Для закачки - прописано 134 2. Для сохранения и отображения - прописано 2013-08-10 Ты эти версии только что прописал и у тебя загрузился один экран тайлов. Предположим, у тебя в кэше до этого были тайлы версии 133, они сохранились под какой-то датой, скажем 2013-07-20. И вот ты, по ПКМ выбрал эту дату, тебе отобразились старые тайлы и в версии "2" в настройках карты у тебя теперь прописана эта новая дата 2013-08-10 -> 2013-07-20 (в версии "1", по прежнему 134). Теперь ты сдвигаешь карту на один экран, в желании посмотреть 133-ю версию и далее. Но в кэше там вдруг оказалось пусто и качалка полезет в интернет и скачает оттуда 134-ю версию и сохранит её под датой 2013-07-20 и что ты будешь теперь делать?

(0012398) vdemidov (manager) 14-08-2013 11:29	Согласен криво выходит. Именно поэтому я соседнем инциденте размышлял о версии отображения и отключении закачки если она не равна текущей.

(0012399) vdemidov (manager) 14-08-2013 11:31	Просто я пока смутно представляю как это сделать логично и предсказуемо и при этом достаточно гибко.

(0012400) zed (manager) 14-08-2013 11:38 edited on: 14-08-2013 11:40	>Просто я пока смутно представляю как это сделать логично и предсказуемо и при этом достаточно гибко. 1. Для закачки - прописано 134 2. Для сохранения - прописано 2013-08-10 3. Для отображения - прописано 2013-07-20 Тогда ты вручную изменяешь 1 и 2, а 3 у тебя будет меняться через ПКМ. И тогда ты сможешь управлять качалкой, если 2 <> 3.

(0012402) vdemidov (manager) 14-08-2013 11:45	Ну похоже как-то так и должно быть. И в первую очередь нужно разделить таки (1. Для закачки) и (3. Для отображения)

(0012403) vasketsov (manager) 14-08-2013 11:49 edited on: 14-08-2013 11:51	>1. Для закачки - прописано 134 >2. Для сохранения - прописано 2013-08-10 Вообще-то если 2013-08-10 однозначно определяется по 134 - вообще не надо заводить отдельно 2013-08-10. Достаточно отдельной доработкой научиться показывать даты версий вместо версий (ну или 'дата [версия]'), если такие даты есть и поддерживаются хранилищем. К вопросу о справочнике версий ))) пусть хотя бы и снаружи в виде раздела в params.txt. Не вижу смысла управлять атрибутом версии отдельно от самой версии.

(0012405) vdemidov (manager) 14-08-2013 11:55	> Не вижу смысла управлять атрибутом версии отдельно от самой версии Убедил. Похоже нужно для версии заводить что-то типа атрибутов "Название", "Описание", "Дата"

(0012406) zed (manager) 14-08-2013 11:55	>К вопросу о справочнике версий ))) пусть хотя бы и снаружи в виде раздела в params.txt. Кстати, да - завести алиас для версий. В хранилище будет сохраняться версия, а при отображении можно выводить комбинацию "версия + алиас". Эта идея мне больше нравится, чем заводить 3 версии.

(0012409) vasketsov (manager) 14-08-2013 12:13	>нужно для версии заводить что-то типа атрибутов "Название", "Описание", "Дата" В СУБД для версий есть текстовое описание, целое число и дата (ну ещё идентификатор, но сути он тут не меняет). Основное использование - определение способа сравнимости версий (больше-меньше), по умолчанию версии несравнимы. Собственно эту же задачу (сравнимости) придётся решать и в случае другого хранилища (в том числе для сортировки версий по ПКМ). При создании новой версии в справочнике происходит попытка заполнить эти поля, а в название версии падает Version. Дата текущая (если только не из тайла или метки, но это тут неприменимо). Сравнивать версии можно по числу (арфиметически), по дате (как дабл) или по названию (строке). Поле типа "описание" - ну не знаю, может и надо для эстетов. По мне так изначально достаточно просто сохранять дату для версии + указать формат вывода в интерфейсе. Всё равно по 134 только дату первого прилёта можно автоматически заполнить (ну максимум ещё TryStrToInt чтобы сравнивать численно, если понадобится). Любые описания и прочие феньки всё равно только руками туда заносятся.

(0012424) vdemidov (manager) 15-08-2013 10:53	Итого для каждой версии хочется иметь несколько полей: 1. Версия для генерации url при закачке 2. Версия для тайлохранилища (название для отображения по правой кнопке) - по умолчанию совпадает с версией для url. 3. Поле для сортировки версий. 4. Дата, по-умолчанию, текущая. 5. Может быть описание для эстетов и ручного заполнения. Как это все оформить в виде програмных интерфейсов, что бы было более-менее универсально для СУБД, версионного беркли и файловых тайлохранилищ?

(0012425) zed (manager) 15-08-2013 11:29	2. Версия для отображения. Мы же уже вроде бы договорились, что тайлохранилище должно сохранять тайл под той версией, под которой тайл был загружен. А по поводу интерфейсов - это по-моему вообще всё может оказаться за пределами хранилищ. Ведь самому хранилищу не обязательно знать, как пользователь собирается интерпретировать версии. Поэтому и хранить всю эту метаинформацию о версиях/сортировке и проч. нужно где-то в импровизированной БД (в том же StorageConfig.ini в папке с хранилищем). Верхний уровень это у нас по-моему TMapType - вот там и вести все манипуляции с версиями, абстрагируясь от типа хранилища.

(0012426) vdemidov (manager) 15-08-2013 11:35	Возможно и даже скорее всего работу с версиями нужно выделять в отдельную сущность, что бы не захламлять интерфейс самого тайлохранилища, но вот задавать и управлять ею ИМХО дело конкретного экземпляра тайлохранилища. Слишком уж разные способы хранения версий в кеше GE, СУБД и версионном беркли. Или ты предлагаешь выбросить совместимость со всем этим?

(0012427) zed (manager) 15-08-2013 11:41	А как по-тоему хранилище должно управлять версиями? Хранилищу максимум нужно попросить у кого-то "сверху" сравнить 2 строковые версии. И всё. Не понимаю о какой потери совместимости идёт речь.

(0012428) vdemidov (manager) 15-08-2013 11:44	Список существующих версий со всеми полями кто должен хранить тайлохранилище или оно должно получать его сверху?

(0012429) zed (manager) 15-08-2013 11:45	Сверху.

(0012430) vdemidov (manager) 15-08-2013 11:47	Расскажи это хранилищу в СУБД и хранилищу GE

(0012431) zed (manager) 15-08-2013 11:50	Раскрой свою мысль шире. Я не понимаю проблемы. P.S. Хранилище GE я сейчас переписываю и избавляюсь от IMapVersionGE, если ты об этом.

(0012432) vdemidov (manager) 15-08-2013 11:55	Хорошо, забудем про GE. Но в СУБД есть своя таблица со всеми полями для версий, есть все механизмы для управления версиями. Какой смысл в дублировании этой системе на клиенте?

(0012433) vasketsov (manager) 15-08-2013 12:01	>3. Поле для сортировки версий >4. Дата, по-умолчанию, текущая Если хранить список версий в памяти уже отсортированным, то для сортировки версий _достаточно_ иметь само значение Version и дату версии (которую в крайнем возможно будет поправить руками и перезапуститься). В СУБД необходимость в дополнительных полях связана с тем, что существуют прямые запросы по диапазонам координат (x between X1 and X2 and y between Y1 and Y2), для которых надо корректно формировать order by по полям. Если этого в других хранилищах нет (а этого нет) - значит этого не надо. А достаточно логическую сортировку по Version (3.99.0 < 3.101.0) плюс признак сортировки по дате, а не по Version. >2. Версия для тайлохранилища (название для отображения по правой кнопке) Уверен? Имхо предостаточно иметь единый ФОРМАТ отображения версии по ПКМ и в прочих списках (например, в свойствах карты сделать combo с версиями). На самом деле, если задан формат, даже можно признак сортировки по дате не делать, а всегда использовать логическую сортировку по результату формата от версии и даты. >5. Может быть описание для эстетов и ручного заполнения А где оно будет отображаться? Если опять же в выпадающих списках - то опять же format достаточно - просто в него добавится текст (вряд ли ты хочешь, чтобы любой юзер мог любой версии присовокупить произвольный текст и его отображать))). Итого минимально достаточно для каждой версии иметь (кроме Version) только DateTime публикации версии (автоматом текушая дата и время в момент прилёта). А формат отображения (на основании Version и DateTime, типа '%D - %V' или '%D %T - %V' - описание) может быть общим для всех версий. Если потакать эстетам - возможно добавляется признак сортировки по дате (который фактически будет означать несравнимость версий по Version, как для DG), и добавляется произвольный комментарий. В сумме 2-4 поля. >Или ты предлагаешь выбросить совместимость со всем этим? А что подразумевается под совместимостью? Какой набор операций потребуется? Кстати, вспомнил, как заполняется произвольный комментарий к версии в СУБД. Если версия строится на основании метки (полигона) из поиска доступных снимков, то туда могут попасть некоторые параметры снимка (типа цветности).

(0012434) zed (manager) 15-08-2013 12:03	>Какой смысл в дублировании этой системе на клиенте? А если посмотреть с другой стороны - зачем это дублировать в СУБД, если всё это будет храниться в универсальном виде вне хранилища. Просто в СУБД это было предусмотрено изначально, но никаких механизмов в самом SAS ведь нету и ту табличку в СУБД не отредактировать. А теперь ты предлагаешь равняться на СУБД? Ну, тогда надо делать опять же внешний интерфейс, а уже СУБД пускай наследует его и вместо сохранения данных в ini, будет писать сразу в БД.

(0012435) zed (manager) 15-08-2013 12:09	По поводу СУБД в SAS у меня вообще смутные сомнения что оно уже давно не работает. Или если и работает, то только с какой-то устаревшей версией dll, потому как в SACS там было достаточно много правок с момента возникновения форка.

(0012436) vasketsov (manager) 15-08-2013 12:17	>хранить тайлохранилище или оно должно получать его сверху? >Сверху. Нереально. Если хранилище само поддерживает список версий - это _референсный_ список версий, до всех остальных версий хранилищу дела нет вообще и полностью. Если сверху надо навесить какие-то атрибуты на версии - хранилищу это совершенно не обязательно знать. Если добавляется новая версия - хранилищу достаточно узнать это в момент сохранения тайла с этой версией. А самое интересное - представь себе процедуру подключения нового саса с нового рабочего места к уже давно существующему хранилищу, и что сверху в хранилище придёт пустой список версий )))) >Какой смысл в дублировании этой системе на клиенте? Вот и мне интересно ))) Я ещё могу понять проблемы со шлюзом API для выхода в DLL через stdcall и callback, с тем что сейчас управление версиями фактически только внутри DLL и живёт (через внутренний браузер). Это как раз следствие того, что остальные тайлохранилища до этого не доросли, и чтобы это было только снаружи. Но вот если уже доросли и надо список версий держать (хотя он и так у меня держится в памяти, например, если включён признак VersionInCache или требуется возвращение тайла предыдущей версии в файловом хранилище), то смысла велосипедить нет. Управление версиями в тайлохранилище СУБД уже обкатано и пашет как часы. Даже отсортированные версии умеет возвращать. Правда вот только сами значения возвращаются, без даты (то есть например для DG можно вернуть только цифробуквы, отсортированные по невидимой дате). В этом смысле ничего дублировать не надо, достаточно только иметь формат отображения версии.

(0012437) zed (manager) 15-08-2013 12:22	>Если сверху надо навесить какие-то атрибуты на версии - хранилищу это совершенно не обязательно знать. Так и я об этом. И разговор по-моему как-раз именно об атрибутах. Хранилище храни версию. Всё. Атрибуты для данной версии хранит САС как ему угодно.

(0012438) vasketsov (manager) 15-08-2013 12:26	>никаких механизмов в самом SAS ведь нету и ту табличку в СУБД не отредактировать Неправда. Во-первых, по ПКМ внизу зовётся внутренний броузер, в котором всё это отображается и правится руками. Во-вторых, возможно создание версии по метке, в частности, по полигону (это было сделано до форка), а также по сохраняемому тайлу (а это сделано только внутри DLL, и пофигу на хост). >если и работает, то только с какой-то устаревшей версией dll Работает с актуальной, так как совместимость поддерживается. Есть некоторые ограничения, типа по ПКМ внизу пункт есть только для основной карты, для слоёв нет, в sacs уже есть поменюшка. >надо делать опять же внешний интерфейс, а уже СУБД пускай наследует его Технически на этом уровне это без разницы, если взять лишний QueryInterface от ITileStorage или при создании ITileStorage (не) передать в конструктор внешний интерфейс хранилища версий. Разница будет потом, насколько дуракоустойчиво получится, насколько корректно будет реализовано удаление версии,...

(0012439) vasketsov (manager) 15-08-2013 12:30	>Хранилище хранит версию. Всё А если этого (одного Version) недостаточно для работы хранилища? >Атрибуты для данной версии хранит САС как ему угодно А сасу может быть угодно хранить атрибуты версий хранилища СУБД не в СУБД? Разве не возможностями хранилища определяется способность его хранить версии и управлять ими?

(0012441) zed (manager) 15-08-2013 12:36	Тут только у одного хранилища "из коробки" есть возможность хранить атрибуты. Для остальных по-любому нужно что-то городить сверху.

(0012442) vasketsov (manager) 15-08-2013 12:41	Ну очевидно которые не умеют сами - тем надо в конструкторе передать внешнее хранилище версий.

(0012443) vdemidov (manager) 15-08-2013 12:42	Зачем сверху? Сделать реализацию и пусть версионные хранилища, у которых пока нет своей пользуются, а для СУБД будет своя. Я потому и говорю, что менеджер версий должен создаваться тайлохранилищем.

(0012444) vasketsov (manager) 15-08-2013 12:49	>менеджер версий должен создаваться тайлохранилищем Ну возможно и так, хотя тогда придётся пропихивать в хранилище zmp. Причём надо будет придумать какой-нибудь финт ушами, чтобы этот менеджер корректно работал как при наличии zmp (обычные карты), так и при отсутствии zmp(при работе конвертера и копировании кэша). Либо допиливать конвертер и копир кэша.

(0012445) zed (manager) 15-08-2013 12:50	Предлагаю с zmp не связываться, а хранить всё это дело в ini в папке с кэшем.

(0012446) vdemidov (manager) 15-08-2013 12:52	>хранить всё это дело в ini в папке с кэшем. Я тоже за этот вариант в качестве дефолтного

(0012447) vasketsov (manager) 15-08-2013 12:59	Ну этот вариант всем хорош, кроме того что в карторепозитории его не опубликовать. А если там даты версий - они фиксированы и одинаковые (для всяких гуглояндексов), чего бы их вводить руками каждому по отдельности?

(0012448) zed (manager) 15-08-2013 13:15	Смысл-то как раз ещё и в том, что в том файлике должны быть только реально присутствующие в кэше версии (хранилище должно автоматически туда добавлять новые версии, при обнаружении таковых в кэше). Тогда по ПКМ можно будет выводить весь этот список, плюс как-то помечать версии, которые присутствуют для конкретного тайла, по которому кликнули.

(0012449) vdemidov (manager) 15-08-2013 13:19	Зачем помечать? Просто сделать возможность возвращать весь этот список, или список для попадающих в прямоугольник тайлов (частный случай один тайл).

(0012450) vasketsov (manager) 15-08-2013 14:36	>только реально присутствующие в кэше версии Да как хотите. Я даже zmp свои пишу, мне вообще по барабану ))). Пользоваться сам буду. Например, для SQLite своего внутреннего справочника версий нет, он висит снаружи (хотя вообще говоря можно добавить, но он там не особо нужен внутри). >сделать возможность возвращать весь этот список Ну если говорить про API, то надо кроме возвращения списка версий по прямоугольнику ещё и управление сравнимостью версий (какая версия больше какая меньше, сравнимы ли вообще, сравнимы по Version или по дате), либо оно так и останется жить в СУБД, а в контекстом меню только по caption (как бы он ни получался) и сортироваться. Также надо процу для создания новой версии (руками) по метке - в этом случае заполняются поля по данным из метки (по date или featureId или ещё как, алгоритмы для разных картосервисов есть, их всего несколько). Ну и API для изменения даты версии руками (хотя необязательно, это можно и руками сделать, но тогда сас перезапускать надо будет). Ну и возможно прочее, типа редактирования описания для версии, актуализации справочника версий по хранилищу, и т.п. ------------ ) - особенность SQLite в том, что поля не типизированы. Соответственно order by version работает даже если в version и строки, и числа, и даблы, и пустота,... поэтому для SQLite важно только, сравнимы ли версии в принципе, но это отдано на совесть юзеру, и сравнимость версий постулируется. Поэтому для SQLite и не нужен отдельный справочник версий для управления сравнимостью. Справочник версий используется только если включено VersionInCache и тащится тайл в режиме "если нету - вернуть от предыдущей версии".

(0016559) vdemidov (manager) 09-10-2015 14:01	После долгих раздумий пришел к такому: 1. Будет конфиг сохранялки тайлов, в котором можно указать конкретную версию или указать, что нужно использовать скачанную версию. 2. Будет конфиг закачивалки тайлов, в котором можно указать конкретную версию или указать, что нужно использовать отображаемую базовую версию. 3. Тот конфиг, который уже сейчас есть, который управляет отображаемой версией и указывает нужно ли отдавать тайл другой версии, если тайла с требуемой нет. По умолчанию сохраняется, закачанная версия и качается отображаемая, то есть остается текущее поведение. В операции закачки по области и тп уже сейчас передаются конкретные версии.

Users who viewed this issue
User List	Anonymous (4681x), ingener (1x), gma (1x), Alexander (1x), zed (2x), vdemidov (6x)
Total Views	4692
Last View	21-11-2024 18:05

Issue History
Date Modified	Username	Field	Change
14-08-2013 10:25	vdemidov	New Issue
14-08-2013 10:59	vasketsov	Note Added: 0012393
14-08-2013 11:07	vasketsov	Note Added: 0012394
14-08-2013 11:25	zed	Note Added: 0012396
14-08-2013 11:29	vdemidov	Note Added: 0012398
14-08-2013 11:31	vdemidov	Note Added: 0012399
14-08-2013 11:38	zed	Note Added: 0012400
14-08-2013 11:40	zed	Note Edited: 0012400	View Revisions
14-08-2013 11:45	vdemidov	Note Added: 0012402
14-08-2013 11:49	vasketsov	Note Added: 0012403
14-08-2013 11:51	vasketsov	Note Edited: 0012403	View Revisions
14-08-2013 11:55	vdemidov	Note Added: 0012405
14-08-2013 11:55	zed	Note Added: 0012406
14-08-2013 12:13	vasketsov	Note Added: 0012409
15-08-2013 10:53	vdemidov	Note Added: 0012424
15-08-2013 11:29	zed	Note Added: 0012425
15-08-2013 11:35	vdemidov	Note Added: 0012426
15-08-2013 11:41	zed	Note Added: 0012427
15-08-2013 11:44	vdemidov	Note Added: 0012428
15-08-2013 11:45	zed	Note Added: 0012429
15-08-2013 11:47	vdemidov	Note Added: 0012430
15-08-2013 11:50	zed	Note Added: 0012431
15-08-2013 11:55	vdemidov	Note Added: 0012432
15-08-2013 12:01	vasketsov	Note Added: 0012433
15-08-2013 12:03	zed	Note Added: 0012434
15-08-2013 12:09	zed	Note Added: 0012435
15-08-2013 12:17	vasketsov	Note Added: 0012436
15-08-2013 12:22	zed	Note Added: 0012437
15-08-2013 12:26	vasketsov	Note Added: 0012438
15-08-2013 12:30	vasketsov	Note Added: 0012439
15-08-2013 12:36	zed	Note Added: 0012441
15-08-2013 12:41	vasketsov	Note Added: 0012442
15-08-2013 12:42	vdemidov	Note Added: 0012443
15-08-2013 12:49	vasketsov	Note Added: 0012444
15-08-2013 12:50	zed	Note Added: 0012445
15-08-2013 12:52	vdemidov	Note Added: 0012446
15-08-2013 12:59	vasketsov	Note Added: 0012447
15-08-2013 13:15	zed	Note Added: 0012448
15-08-2013 13:19	vdemidov	Note Added: 0012449
15-08-2013 14:36	vasketsov	Note Added: 0012450
20-08-2013 12:15	vasketsov	Relationship added	related to 0001984
20-08-2013 12:15	vasketsov	Summary	Разделить версию для закачки от версии для тайлохранилища => Разделить версию для закачки от версии для тайлохранилища (+ справочник версий)
23-08-2013 14:07	vdemidov	Relationship added	parent of 0002112
23-08-2013 14:15	vdemidov	Status	new => confirmed
23-08-2013 14:15	vdemidov	Summary	Разделить версию для закачки от версии для тайлохранилища (+ справочник версий) => Разделить версию для закачки от версии для отображения
23-08-2013 14:15	vdemidov	Description Updated	View Revisions
23-08-2013 14:15	vdemidov	Additional Information Updated	View Revisions
20-09-2013 20:13	zed	Relationship added	child of 0002176
04-11-2013 14:23	vdemidov	Target Version	24xxxx => 140303
03-03-2014 08:47	vdemidov	Target Version	140303 => 140404
19-03-2014 08:03	vdemidov	Target Version	140404 => 141111
29-05-2014 12:27	vdemidov	Relationship added	child of 0002439
23-10-2014 09:07	vdemidov	Target Version	141111 => 150915
21-01-2015 10:39	vdemidov	Target Version	150915 => 151010
04-08-2015 10:10	vdemidov	Tag Attached: версионный кэш
04-10-2015 15:28	vdemidov	Target Version	151010 => 151111
09-10-2015 14:01	vdemidov	Note Added: 0016559
06-11-2015 08:20	vdemidov	Target Version	151111 => 191221
23-07-2019 17:04	vdemidov	Target Version	191221 => 211230
30-12-2021 08:59	zed	Target Version	211230 => 26xxxx

SASGIS