Использование в Sas.Планета кеша в формате Berkeley

[vdemidov]

Вы неправильно понимаете. Тип кэша полностью задает структуру папок и файлов. В том числе и в случае, если файлы это контейнеры для больше чем одного тайла.

Если при обычном, файловом кэше мы специально указываем его тип, чтобы программа знала, как его обрабатывать

Мы нигде не указываем ничего кроме типа кэша. Он задает всю структуру.
Тип Беркли жестко задает все, в том числе и формат метаданных внутри контейнеров. Именно поэтому первые версии кэша на основе БерклиДБ никак не совместимы с современной программой.
На основе БерклиДБ можно сделать кучу разных типов тайлохранилищ. Но тот что есть сейчас жестко задан и ничего общего ни с файловым САС.Планеты, ни с файловым GMT ни со всеми остальными не имеет.

Следующий вопрос по Беркли: если процесс конвертирования не прошёл до конца и был закрыт, то, желая в дальнейшем всё-таки его завершить, что нужно сделать, а чего, наоборот, делать не следует?

Ровно все то же как если бы вы копировали или переносили файлы в файловом менеджере.

[Parasite]

Вот именно, "случайное". Названия папок и файлов имеют значение при многих операциях, выполняемых программой. Взять то же построение карты заполнения. Если при обычном, файловом кэше мы специально указываем его тип, чтобы программа знала, как его обрабатывать, то при кэше Беркли мы указываем только тип "Беркли", а что там внутри? Логика подсказывает, что любой тип кэша при упаковке в Беркли должен быть конвертирован в какой-то единый тип, "случайно" им оказался тип "SAS.Планета". Почему бы не подтвердить этот факт?

Если я правильно понял весь вопрос... "тип кэша" для программы есть последовательность операций от стадии "Хачу тайл Х\Y\Z" и до физического местонахождения контента на диске (файла) в случае "Тайловый кэш". В случае же с Беркли - часть "от XYZ до контента" грубо говоря берется на себя базоводом, и программа знать не знает - где физически лежит тайл, который она просит. Она просто хочет этот тайл от базовода - и базовод ей его или дает, или не дает (вернее, дает ответ "Не дам"). Физически же он вообще может лежать в кластере на другом конце света в пределах архитектуры того базовода - это уже забота не саса.

В этом смысле утверждать "любой тип кэша при упаковке в Беркли должен быть конвертирован в какой-то единый тип тайлового кэша" - как-то изначально коряво. Ничего никуда по тайлам не приводится - базовод просто создает тот или иной контейнер с уникальными метками Х\Y\Z для каждого хранимого в нем тайла, и внутренняя структура оного контейнера побайтно - уже забота базовода а не САСа. И этот "тип" называется "база данных беркли", кой базовод есть сторонняя сущность и его разработчики знать про сас не знают.

Следующий вопрос по Беркли: если процесс конвертирования не прошёл до конца и был закрыт, то, желая в дальнейшем всё-таки его завершить, что нужно сделать, а чего, наоборот, делать не следует?

Если был закрыт аварийно (например закрытием процесса саса) - то идти укачивать утили от зеда и восстанавливать базы.

[DJ VK]

Следующий вопрос по Беркли: если процесс конвертирования не прошёл до конца и был закрыт, то, желая в дальнейшем всё-таки его завершить, что нужно сделать, а чего, наоборот, делать не следует?

Если был закрыт аварийно (например закрытием процесса саса) - то идти укачивать утили от зеда и восстанавливать базы.

Пока, слава Богу, все работает. Прерванный процесс (отрубание питания не пробовал, обычно стараюсь сам выключать программу) продолжается, так же как и скачка, заданием повторно той же задачи. Полученная база внешне глюков не выдает...
А вот два момента немного расстраивают
1)база данных обновляется не в реальном времени, запросто при упаковке может пропасть хоть гигабайт места на диске (вместо ожидаемого высвобождения места за счет оптимизации), а потом, через пару часов, возникнуть снова. (Эффект не наблюдается если упаковка первоначальная и область выделения делается в границах 1го файла базы.)
2)скорость упаковки маленькая. особенно если хочется весь кэш сжать время неоправданно долгое. Есть метод с виртуальным файлом транзакций, но он немного грубоват, не хочется убить кэш созданный в течение полугода...

[Papazol]

Хорошо, давайте тогда разберём пример. Намеренно упрощаю всё до уровня плинтуса, чтобы не отвлекаться на частности.
Сначала возьмём файловый кэш. Станем выводить на экран тайл из этого кэша.
При типе кэша "SAS.Планета" тайл z\x\y будет запрошен из места, описываемого путём ...\z\x\y, ибо такое его расположение задано самим типом кэша. Если же тип кэша "GMT", то этот же тайл z\x\y будет запрошен уже из другого места, описываемого путём ...\z-1\x\y. Вот это z-1 есть формула пересчёта при переходе от основного типа кэша к другому. Если её применять ко всем тайлам, то все тайлы будут выведены правильно. Чтобы программа могла применять нужную формулу пересчёта, мы указываем тип кэша в zmp.
Теперь упакуем наш кэш в БД. Неважно, как устроена эта БД. Программа должна обратиться к ней и запросить у неё тайл z\x\y. Поскольку программа теперь имеет информацию только о том, что тайлы хранятся в БД, и не имеет информации о типе кэша, она не может сама применить формулу пересчёта. Значит, эту формулу должна применить БД. А отсюда следует, что в БД должна храниться информация об изначальном типе кэша, который в неё упакован. Даже не так. Тип кэша для БД - тарабарщина. Должна быть прописана сама формула пересчёта.

Я это всё хочу выяснить не просто для общего развития. Не хотелось бы потратить много часов на переконвертирование большого кэша туда-сюда.
Про прерванный акт процесс конвертирования я понял, речь шла о прерывании вручную, а не аварийном.
Родился ещё один вопрос. Если я упакую карту в БД, я смогу потом её экспортировать в упакованный кэш для SAS4WinCE? Карту, формат кэша у которой был GMT.

[Tolik]

Поскольку программа теперь имеет информацию только о том, что тайлы хранятся в БД, и не имеет информации о типе кэша

Имеет!
Кэш Беркли - это не какая-то абстрактная БД в вакууме. Это неотъемлемая часть САС.Планеты, и она (Планета) прекрасно знает, как достать оттуда нужный тайл. В какую пойти директорию, какой файл открыть, какой там индекс или чё прочитать и какую запись в нём найти.
Представьте себе просто кэш типа САС, в котором директория последнего уровня с файлами jpg заменена на архив, в котором лежат эти картинки. Только это не архив, а база данных. Упрощённо. Понятно теперь?

Я это всё хочу выяснить не просто для общего развития. Не хотелось бы потратить много часов на переконвертирование большого кэша туда-сюда.

И всё-таки я не понял, зачем вам это надо. Допустим, вы ничего не знаете про то, как хранится кэш. Где-то хранится и ладно. Как это повлияет на переконвертирование его туда-сюда много часов?

Если я упакую карту в БД, я смогу потом её экспортировать в упакованный кэш для SAS4WinCE?

Конечно! Какая разница, где и как хранятся тайлы?? САС знает, как их оттуда вытащить!

Карту, формат кэша у которой был GMT.

А вот это как раз не имеет значения. И вообще неизвестно, какой когда-то был формат кэша.

Был некий тайл, лежал в какой-то директории и как-то назывался, например 12/0/34/0/56.jpg. При конвертации кэша его положили в другую директорию и переименовали, например, qqqrrrsssttt.jpg. Сама картинка осталась, информация о её прошлой жизни не сохранилась.

[Papazol]

И всё-таки я не понял, зачем вам это надо. Допустим, вы ничего не знаете про то, как хранится кэш. Где-то хранится и ладно. Как это повлияет на переконвертирование его туда-сюда много часов?

Разве плохо, если кто-то хочет знать чуть больше, чем знал раньше? Я же не лезу в код и т. п. Мне важен принцип работы. Если я буду точно знать, что получится в результате моих действий, я смогу достичь нужного результата меньшим их числом.

Карту, формат кэша у которой был GMT.

А вот это как раз не имеет значения. И вообще неизвестно, какой когда-то был формат кэша.

Если это всё так, я очень рад. Но уточнить перед тем, как пытаться конвертировать гигабайты, всё же необходимо.

[zed]

А вот два момента немного расстраивают
1)база данных обновляется не в реальном времени, запросто при упаковке может пропасть хоть гигабайт места на диске (вместо ожидаемого высвобождения места за счет оптимизации), а потом, через пару часов, возникнуть снова. (Эффект не наблюдается если упаковка первоначальная и область выделения делается в границах 1го файла базы.)
2)скорость упаковки маленькая. особенно если хочется весь кэш сжать время неоправданно долгое. Есть метод с виртуальным файлом транзакций, но он немного грубоват, не хочется убить кэш созданный в течение полугода...

1. А этот лишний гигабайт случайно не в папке env сосредотачивается?
2. Метод с "виртуальным файлом транзакций" это помещение папки env на RAM диск? По-моему, это оптимальный вариант для тех, хоть чуть-чуть технически подкован и не падает в обморок от слова RAM-диск. Убить накопленный годами кэш тут никак не получится:
- RAM-диск создаётся только на время конвертирования кэша
- при перегонке кэша нужно не перемещать, а копировать тайлы из исходного кэша
- по завершении копирования, нужно размонтировать RAM-диск, а его содержимое (папку env) вернуть на место
- при желании, выполнить проверку нового кэша
- удалить вручную старый кэш

Если же при конвертировании и использовании RAM-диска были сбои системы (завис САС, винда в BSOD упала и т.д.), нужно запустить известную утилитку, исправить возможные ошибки и продолжить процесс.

P.S. Кстати, после конвертирования в кэш Беркли рекомендую сразу же перезапустить САС.

[Tolik]

P.S. Кстати, после конвертирования в кэш Беркли рекомендую сразу же перезапустить САС.

Кстати, мне кажется, конвертор кэша лучше вынести из САСа в отдельную программу. И позаботиться, чтобы САС был закрыт (или по крайней мере чтобы данная БД была закрыта).
У меня возникала мысль, что что-нибудь может закорявится, если одновременно конвертировать кэш и лазить по той же карте. Не проверял.

[zed]

Вот это z-1 есть формула пересчёта при переходе от основного типа кэша к другому. Если её применять ко всем тайлам, то все тайлы будут выведены правильно. Чтобы программа могла применять нужную формулу пересчёта, мы указываем тип кэша в zmp.

Если упрощать до плинтуса, то аналогичная формула есть и для кэша Беркли и САС с лёгкостью пересчитывает и находит нужный тайл при любых операциях - главное а zmp указать правильный тип. Для конечного пользователя нет абсолютно никакой разницы как и в каком кэше хранится тайл - все действия прозрачны.

У меня возникала мысль, что что-нибудь может закорявится, если одновременно конвертировать кэш и лазить по той же карте. Не проверял.

Теоретически - не должно. На практике - кэш не портится, но без перезапуска, карта может перестать работать и вылетит AV. Где-то что-то не стыкуется (баг?).

[Parasite]

Кэш Беркли - это не какая-то абстрактная БД в вакууме. Это неотъемлемая часть САС.Планеты, и она (Планета) прекрасно знает, как достать оттуда нужный тайл.

На самом же деле - это таки абстрактный базовод libdb51.dll в вакууме в папке САСа, производства одной малоизвестной шарашки "Oracle". Он вполне себе "отъемлем" от САС.Планеты (более того - САС без этой ДЛЛки даже нормально пущается и работает, если в активных картах\слоях нет кэша в формате беркли). И да - САС не знает, где лежит тайл в базе, по каким байтовым смещениям итд - это знает вышеуказанная ДЛЛка, а САС просто умеет у нее спрашивать нужное при обработке кэша типа "беркли".

Пока, слава Богу, все работает. Прерванный процесс (отрубание питания не пробовал, обычно стараюсь сам выключать программу) продолжается, так же как и скачка, заданием повторно той же задачи. Полученная база внешне глюков не выдает...

Повезло.
А у меня, при проработке бага 1592 (так до конца и не прибитого на больших выделениях, так что далеесказанное - в силе) база валится - только в путь. При каждом подвисании\перезапуске - получаем насущную необходимость во многодневной проверке баз, ибо при повторном запуске в ту же базу - закачка просто не стартует, а висит на первом же тайле. После чистки зедовыми утилями - все ОК до следующего раза.