0001481: Переделка хранилища меток

Notes
(0008237) zed (manager) 09-08-2012 17:19	>Ввести хотя бы гзип Т.е. то, что этот огромный файл, прежде чем загрузить/сохранить придётся ещё и утаптывать архиватором, по-твоему должно придать скорости?

(0008238) Papazol (reporter) 09-08-2012 19:58	Пусть не архиватор, но думать об этом надо. Возможно, применить бинарный формат хранения меток, может, это уменьшит пузо sml? Или какой-либо из распространённых форматов типа gpx или kml. Также неплохо было бы иметь возможность хранить метки в нескольких (а лучше во многих) файлах. Оперировать с несколькими небольшими файлами быстрее, чем с одним огромным.

(0008242) Parasite (administrator) 10-08-2012 03:26 edited on: 10-08-2012 03:26	>по-твоему должно придать скорости? Ну гуглу же с его KMZ - оно ничем не мешает, не так ли? А там - обычный зип поверху текстовичков. Да, и по-моему я написал "Предлагаю подумать". Вместе. Всем. Никаких жестких утверждений выше не было - это рефакторинг, а не хотелка. То есть, с удовольствием выслушаем и обсудим все варианты, ибо sml пухнет таки безмерно. При нескольких десятках меток - еще куда ни шло, а вот при тысячах - вот, например, очередное: http://sasgis.org/forum/viewtopic.php?p=29428&#p29428

(0008245) Tolik (reporter) 10-08-2012 05:58	Тут на самом деле несколько проблем: 1. файлы .SML просто безбожно распухают (само по себе не страшно) 2. Это влияет на скорость загрузки программы (вот это гораздо хуже) 3. да и не только (а на что ещё?) Вот №2 и надо лечить в первую очередь. Как-то изменить алгоритм, чтобы САС не считывал весь файл в память... Может, как-то это дело проиндексировать... Может, в базу Беркли запихнуть? Опыт работы уже есть, dll тоже. А размер файла, действительно, можно уменьшить зипом.

(0008246) vdemidov (manager) 10-08-2012 06:30	Раскрою маленький секрет, оно сейчас не только полностью считывается в память, а еще и хранится в двух экземплярах, а при сохранении вообще в 3-х экзеплярах в памяти держится. Начинать нужно с независимого от MidasLib парсера. То есть с хотелки 0001217 Жду предложений.

(0008247) Fetser (reporter) 10-08-2012 06:58	А такой вариант возможно реализовать? Файлы kml/kmz хранятся в определённой папке и подпапках. И есть некий файл в котором записана структура папок (она по сути и является категориями меток), наличие файлов и статус видимости. Программа при запуске или по команде "Обновить" сверяет наличие kml с этим файлом и вносит изменения. И отображает на экране только те kml у которых статус "видимые". По сути импортирует их, но не в файл а сразу для показа.

(0008248) vdemidov (manager) 10-08-2012 07:15	Реализовывайте. Разрешаю.

(0008249) Fetser (reporter) 10-08-2012 07:20	> Реализовывайте. Разрешаю. Вопрос о возможности подразумевает теоретическую возможность данной реализации, а не просьбу разрешить :) В русском языке "Возможно" и "Можно" имеют разный смысл.

(0008250) Parasite (administrator) 10-08-2012 07:28	>Может, в базу Беркли запихнуть? Опыт работы уже есть, dll тоже. А если тупенько в SQLite сунуть?

(0008251) vdemidov (manager) 10-08-2012 07:32	Суй. Но не забудь написать конвертер для старого кэша в новый формат, и будешь лично объяснять всем чайникам куда пропали все их нажитые непосильным трудом метки и как их получить обратно.

(0008252) Papazol (reporter) 10-08-2012 07:35	Как это сделано в Google Earth?

(0008253) Tolik (reporter) 10-08-2012 07:36	Конвертер, безусловно, понадобится, это не обсуждаем. Кто чего будет совать - тоже. Расскажите лучше алгоритм работы. Зачем в 2-х и 3-х экземплярах. Можно ли не считывать в память.

(0008255) vdemidov (manager) 10-08-2012 07:48	Первый экземпляр, самый нужный, это в виде объектов. Он самый экономный. На одну точку трека или полигона тратится 16 байт плюс немного служебной инфы. Второй экземпляр, это DataSet, из которого все объекты вычитываются и в кторый сохраняются. Тут я не уверен сколько памяти тратиться, но как минимум 24 байта на одну точку трека (а может и 32 или даже 64) плюс куча накладных расходов на все остальное. Третий экземпляр, это все содержимое sml файла при операциях чтения и записи. Расходы можете сами прикинуть, но минимум 32 байта на точку трека плюс куча всякой фигни.

(0008256) vdemidov (manager) 10-08-2012 07:50	От второго и третьего экземпляров можно легко избавиться даже не меняя формата файлов, если задействовать SAX-подобный парсер XML. Но у меня руки не доходят.

(0008257) vdemidov (manager) 10-08-2012 07:57	Кстати. В kml расходы на запись точки трека или полигона в приличной точности составляют 35-36 байт.

(0008258) Parasite (administrator) 10-08-2012 08:19 edited on: 10-08-2012 08:20	А если в GPB? Он весьма компактен, и к тому же и расширяем. Чего изобретать велосипед...

(0008259) vdemidov (manager) 10-08-2012 08:32 edited on: 10-08-2012 08:32	Что такое GPB?

(0008260) Parasite (administrator) 10-08-2012 08:35	GoogleProtocolBuffers

(0008261) vdemidov (manager) 10-08-2012 08:38	Ааа. В этом смысле. Нету нормального врапера для делфы. Ну или по крайней мере я не знаю такого.

(0008262) vasketsov (manager) 10-08-2012 09:16	>гуглу же с его KMZ - оно ничем не мешает, не так ли? Если в GE открыть kml размером мешков этак с 20, скажем это земельные участки района с росреестра, он тоже будет еле шевелиться как коматозник. А если всю область таких районов в 40.... >Файлы kml/kmz хранятся в определённой папке и подпапках Логично. >И есть некий файл в котором записана структура папок (она по сути и является категориями меток), наличие файлов и статус видимости. Возможно тут достаточно и самой структуры папок, а возможно и нет, видимость можно делать атрибутами файлов например. Но может быть беда с правами. >отображает на экране только те kml у которых статус "видимые". Это и так. Видимо имеется в виду, что выгружает отключаемые и загружает включаемые категории (файлики)? Формат gpx практически исключается сразу, так как придётся писать собственное расширение.

(0008263) Parasite (administrator) 10-08-2012 09:27	>Если в GE открыть kml размером мешков этак с 20, скажем это земельные участки района с росреестра, он тоже будет еле шевелиться как коматозник. А если всю область таких районов в 40.... Знаю. Но тикет про файлы хранилища и размер оных (на диске) и соответственно долгий старт саса сугубо от чтения многих мегабайт, а не про тормоза при отрисовке всего этого честно нагугленного. Банальный зип топчет SML раз в 5 с ходу. Отрисовку - это в другой тикет, если кому-то мешает. Мне - пока что нет.

(0008264) Fetser (reporter) 10-08-2012 09:31	>Видимо имеется в виду, что выгружает отключаемые и загружает включаемые категории (файлики)? совершенно верно >видимость можно делать атрибутами файлов например. Но может быть беда с правами. А можно видимость задавать расширением. Например .sas1 видимые .sas2 невидимые

(0008265) Tolik (reporter) 10-08-2012 09:31	> долгий старт саса сугубо от чтения многих мегабайт Наверно не от чтения, а от парсинга? Поэтому надо парсить не всю подряд информацию, а только самую необходимую. Значит, нужна структура типа базы данных, чтобы всякие имена меток и цвета линий вытаскивались оттуда только при необходимости, а не считывались в память при старте программы.

(0008266) vasketsov (manager) 10-08-2012 09:47	>не от чтения, а от парсинга? Я может глупость прошу, ноу нас есть на эту тему счётчики производительности? Их кто-нибудь анализировал? А то я совсем не в курсе. >нужна структура типа базы данных Ну в общем-то если под "типа" понимать возможность выполнения прямого запроса "а ну-ка дай-ка метки в диапазоне lon-lat-lon-lat" - то да, но вообще говоря не очень понятно, что мешает сейчас это делать, только ли отсутствие индекса по координатам (возможно для скорости даже типа quadkey), или что-то другое.

(0008267) Tolik (reporter) 10-08-2012 09:53	Это было бы вообще круто. Запрос к БД только для определённого экрана. Только для окна Управление метками нужен ещё индекс по именам и категориям. Что-то не соображу, это легко сделать?

(0008268) vasketsov (manager) 10-08-2012 09:53	Ну и кроме того особняком вообще имеет место задача подключить kmz в режиме read-only, если его метки не надо ни править, ни импортировать в базу меток, ни ещё чего нибудь делать, что только может быть возникнет в будущем. Ровно ничего. Только показать. Соответственно настройка видимости, цветов и линий -только на уровне всего kmz целиком. Этакая внешная ссылка из базы меток на kmz. Не знаю конечно, насколько быстро это будет работать.

(0008269) vasketsov (manager) 10-08-2012 09:56	>нужен ещё индекс по именам и категориям. Что-то не соображу, это легко сделать? Ну во "взрослых" СУБД это г-новопрос. Легче не бывает. В беркли или других настольных - не знаю.

(0008270) Fetser (reporter) 10-08-2012 09:56	>имеет место задача подключить kmz в режиме read-only Для меня это основное использование. Поскольку kmz создаются другими программами. И смотреть их приходится в больших количествах

(0008271) Parasite (administrator) 10-08-2012 10:05 edited on: 10-08-2012 10:06	>Наверно не от чтения, а от парсинга? Если и от парсинга - то уже после чтения. Ежу ж понятно, что подсосать 100-150Мб файл при старте - это дольше, чем не делать этого. А потом еще и распарсить и отрисовать (и это уже в другой тикет). И не только подсосать, а еще и слить в бэкап. Особенно заметно при слабых винтах - ноуты, нетбуки и прочие недоPC. И проверяется элементарно - достаточно переименовать опухший SML в отсебятину, и САС влетает так, как и должен.

(0008272) Tolik (reporter) 10-08-2012 10:05	Кинуть кучу kmz в спец. директорию и пусть она их все выводит на экран? Но это как раз займёт кучу времени. Фактически их придётся-таки импортировать.

(0008273) Parasite (administrator) 10-08-2012 10:08	>Фактически их придётся-таки импортировать. Причем по одному, распаковывая каждый при обходе всех папок, и даже без какого-либо общего индекса содержимого в этих КМЗ... Наплачемся.

(0008274) vasketsov (manager) 10-08-2012 10:16	Не совсем импортировать в текущем понимании этого. Их надо будет иметь ровно в одном экземпляре в памяти, и просто прочитать и раззиповать (соответственно наличие kmz в памяти саса - исключительно прямо реализуется галочкой видимости, сбросили - выгрузили целиком). Я вот например не знаю, на что больше тратится время, на чтение и парсинг kmz, или на превращение его распарсенных внутренностей в sml. Впрочем эта задача всё равно стоит особняком в этом топеге, это лишь мысль, как и на чём можно сэкономить. Тем более что реально в большинстве случаев kmz - исключительно внешние файлики, и не редактируются. Ещё с дельфёвого форума скульру: наверно уже зимой 2012 C++Builder XE2 уже будет заточена и для Android а к началу лета 2013 и Delphi XE2 2) Про Android и СУБД: - SQLite - клиенты в исходниках - FB, PgSQL, MySQL. Хотя возможно что-то и потребует допиливания, что бы компилилось. А может и сервера запустятся :) - ODBC драйвера в исходниках - MSSQL, Sybase ASE. Читал уже как собирать UnixODBC + FreeTDS под iOS. Наверное и под Android можно. - возможно будет Interbase клиент, а может и IB To Go. 3) Компоненты доступа - все те же знакомые лица. Гриды - FireMonkey, TMS, и кто-нибудь еще. DevEx - ХЗ. но это так, больше к размышлению по мотивам.

(0008275) Tolik (reporter) 10-08-2012 10:16	Короче, идея такая. Все метки хранятся в БД. У неё индексы по категориям/именам и по координатам. При старте ничего не считывается. При выводе на экран карты шлётся запрос в БД "а ну-ка дай-ка метки в диапазоне lon-lat-lon-lat" При работе в окне Управление метками шлются запросы по мере необходимости: "а покажи-ка список категорий", "а какие метки в категории х", "а какие параметры у метки х.у" и т.п. Кто в курсе, покомментируйте, насколько это легко реализуемо. Потом уж можно будет прикрутить групповую работу с этой БД...

(0008276) Fetser (reporter) 10-08-2012 10:22	> Фактически их придётся-таки импортировать наверное придётся но только те какие хочешь посмотреть в данный момент, а не все подряд > распаковывая каждый при обходе всех папок формат может быть любой, не обязательно упакованный. Файл sml тоже прежде чем появится в виде картинок на экране и читается и обрабатывается Я не против базы, но и такой вариант имеет преимущества. если испортится база то испортится всё. А испорченный один файл метки не испортит остальные. Лучше конечно если бы была возможность иметь и базу и такой просмотр kmz лежащих в нужной папке и подпапках не импортируя их в базу

(0008277) Tolik (reporter) 10-08-2012 10:25	Мне кажется, подключение kmz - это тема для другой хотелки. Формат sml читается и обрабатывается, кмк, лучше и быстрее, чем kml. А эта тема про то, как сделать ещё лучше и быстрее, а не наоборот.

(0008278) vasketsov (manager) 10-08-2012 10:32	>покомментируйте, насколько это легко реализуемо Ну, во "взрослых" СУБД это легко реализуемо. В беркли или других настольных - не знаю. >если испортится база то испортится всё На эту тему есть бэкапы.

(0008282) vasketsov (manager) 10-08-2012 13:03 edited on: 10-08-2012 13:05	Прогрузил кучку kmz суммарным размером размером 16 мешков (только полигоны) - 8 минут с несколькими секундами заняло (повторный тест, файлы в кэше ФС). Удалил создание объектов (парсер не трогал, только лишь не создаются объекты) и грузанул это же - 10 секунд. Этот весьма тупенький синтетический тест даёт весьма характерный ответ на простой вопрос - на что тратится время при импорте. Заключается он в том, что сасу практически пофигу что и откуда читать, основное время тратится на создание объектов в памяти.

(0008283) vdemidov (manager) 10-08-2012 13:17	Ну что ж, значит нужно оптимизировать создание объектов.

(0008304) Parasite (administrator) 11-08-2012 04:56	>сасу практически пофигу что и откуда читать, основное время тратится на создание объектов в памяти. Гуд. А с размером хранилища-то (как файлов) чего-нибудь делать будем? Как-то напрягает меня получение, ворочанье и хранение\бэкапирование 160Мб при импорте 25Мб КМЗ, да еще и в 2х копиях рядом, да при каждом старте.

(0008305) Tolik (reporter) 11-08-2012 05:02	Ну это просто: сделать формат smz очевидным способом. Только надо посчитать, что быстрее: считать sml или считать+распаковать smz (то же и с записью). Какой размер получится, если зазиповать 160МБ sml?

(0008314) Parasite (administrator) 11-08-2012 05:36	>Какой размер получится, если зазиповать 160МБ sml? Что-то около 26Мб - +\- как и исходные KMZ, кои по сути есть то же самое.

(0008315) Tolik (reporter) 11-08-2012 05:37	Теперь надо придумать бенчмарк :)

(0008425) zarius (reporter) 13-08-2012 13:17 edited on: 13-08-2012 13:44	Убрать метки в БД - было бы самое то! Кроме всего вышеперечисленного - это позволило бы легко и удобно управлять метками из других приложений. Например, в реальном времени пополнять БД меток новыми маршрутами (хотя для этого сасу еще необходимо иметь возможность обновлять метки).

(0008427) zed (manager) 13-08-2012 13:49	>Убрать метки в БД - было бы самое то! БД бывают разные. Какая из них - самое то?

(0008448) zarius (reporter) 14-08-2012 09:12 edited on: 14-08-2012 09:18	По идее надо СУБД с поддержкой запросов, чтобы можно было осуществить описанное Tolik'ом в посте (0008275). Выбирать надо, имхо, из тех, которые проще в установке, без лишних заморочек и беспроблемны в сопровождении. Какую конкретно выбрать - надо обсуждать. Например вообще простейший вариант: БД в DBF, доступ к ней посредством http://www.sqlite.org/ или стандартного фокспрошного ODBC-драйвера.

(0008449) zed (manager) 14-08-2012 09:20	СУБД хороша, если стоит задача расшаривания меток между несколькими пользователями. Но для домашнего пользователя-одиночки это будет избыточно, монструозно и слишком трудоёмко в настройке/использовании/поддержке. Да и про СУБД уже по-моему тикет где-то был, а здесь скорее про оптимизацию без СУБД, чтобы работало из коробки и не доставляло лишних хлопот.

(0008450) zarius (reporter) 14-08-2012 10:18	Как раз таки избыточности, монструозности и трудоемкости для конечного пользователя надо избегать - полностью согласен. И этого можно избежать - взять тот же SQLite - для пользователя это будет отражено во включенном в состав САСа sqlite3.dll (около 600Kb) - по идее - все. Плюсы использования СУБД не только в расшаривании - это, так сказать, сопутствующий бонус. Имхо, главный плюс в том, что перечислял Tolik (процитирую): "При старте ничего не считывается. При выводе на экран карты шлётся запрос в БД "а ну-ка дай-ка метки в диапазоне lon-lat-lon-lat" При работе в окне Управление метками шлются запросы по мере необходимости: "а покажи-ка список категорий", "а какие метки в категории х", "а какие параметры у метки х.у" и т.п." Этим самым можно достичь многократного увеличения производительности в САСе при больших объемах меток: не надо хранить в памяти, получение из БД только меток из диапазона на экране.

(0008452) zed (manager) 14-08-2012 10:28	Вы что-то путаете, SQLite - встраиваемая БД. И ей до настоящей СУБД как до луны - она только для single-user-mode. Но я согласен, БД всё же лучше подходит на роль хранилища меток, нежели пухлый xml.

(0008473) vasketsov (manager) 14-08-2012 11:35	Граждане, давайте не будет путать тёплое с мягким. Из понтия БД не следует сразу же обязательно возможность выполнения запросов типа SQL. Из понятия БД не следует сразу же обязательно многопользовательская работа. БД - они такие разные.... Главное, что требуется от БД сасу - это ИНДЕКСы. >вообще простейший вариант: БД в DBF Дружище, зачем нам (вам) лишнее "Г"? >Какую конкретно выбрать - надо обсуждать Всё и так предельно тривиально: 1. Для single-user и embedded берётся любая, в которой разбирается zed )))))) в частности и любой другой разработчик (кроме вашего непокорного слуги) вообще. 2. Для любых взрослых СУБД берётся ODBC (и особенно отличившеся извращенцы смогут наверное даже DBF подрубить). Ваш непокорный слуга с разной степенью интенсивности находится именно тут и занимается именно этим (сначала правда кэш, а метки потом, и правда на это вечно нет времени, потому что там нельзя сесть поработать минут на 20-30 ежедневно, там надо заседать часами, но сути это не меняет). Если будут вопросы/советы по структуре - обсудим. Но надо чётко понимать, что любые попытки на голом sml/kmz/SQLite сделать многопользовательность априори обречены на провал, ибо тот 1% многопользовательских юзеров, которым это реально надо, без особенного батхерта поставит взрослую СУБД без подобных проблем, с бэкапами, блекджеком и шлюхами. Сколько лет ждёте - ещё подождёте многопользовательности. 3. Как и любые другие провайдеры кэша/меток - их хорошо иметь много разных. То есть это не (только) вопрос перехода и миграции. Это прежде всего вопрос выбора. А вообще говоря, сейчас БД меток и её бэкап в одном формате, но ничто не мешает иметь их в разных форматах (рабочая - в формате с максимальной скоростю доступа, бэкап - минимаьный размер). 4. При любом формате внешнего хранилища меток, выше показано, что ничуть не менее важным является вопрос внутреннего создания/хранения меток в памяти программы. Прежде всего по скорости. Если чего и забыл - старшие товарищи поправят.

(0008489) zarius (reporter) 14-08-2012 12:10 edited on: 14-08-2012 12:12	хм... вроде бы нигде SQLite СУБД не обзывал, ну да ладно - имел ввиду что при наличии SQLite конечному пользователю при установке САС не потребуется отдельно выполнять какие либо действия по установке СУБД - и это хорошо. >Главное, что требуется от БД сасу - это ИНДЕКСы. >>вообще простейший вариант: БД в DBF >Дружище, зачем нам (вам) лишнее "Г"? согласен что "Г" - прошлый век и много минусов, и тем не менее простейшая БД и есть ИНДЕКСы - на то он и простейший вариант :) Если кэш переводить на СУБД - согласен что мутить что то иное для меток - особого смысла нет.. значит будем ждать...

(0008500) Parasite (administrator) 14-08-2012 13:42	>берётся любая, в которой разбирается zed А еще нам обещали плагины - в т.ч. и про хранение меток так, как душа пожелает...

(0010279) Fed (reporter) 31-12-2012 04:57	Хорошая идея на странице http://sasgis.org/mantis/view.php?id=1753#c10271: vasketsov>Разумеется необходимо соблюсти общий принцип - ДАННЫЕ отделены от их ОТОБРАЖЕНИЯ, соответственно ОТОБРАЖЕНИЕ у всех своё и настраиваемое.

(0010317) vasketsov (manager) 04-01-2013 15:28	В хотелке 0001753 приаттачена модель для СУБД.

(0010382) vasketsov (manager) 14-01-2013 12:41	Что-то имеет смысл делать с неуникальностью имён меток в одной категории? Сейчас собственно "источники" дублирующихся имён такие: а) при импорте тех же KML-ек запросто может быть одинаковое имя у разных объектов (собственно с одинаковыми именами разные метки и залетают, пример - покрытие ESRI в соответствующей теме или обновление гугла, да собственно любые KML-ки, в которых автор не позаботился об уникальности объектов); б) импорт трека или полигона, состоящего из нескольких обособленных кусков; в) можно руками сделать метку с таким же именем, как у существующей метки в этой же категории (или перенести в другую категорию к существующей). Или традиционно забиваем и считаем это фичей? В принципе а) разруливается довольно просто, либо принимается решение о том что метка - дубликат, либо добавляем уникальные данные в имя метки. Случай б) разруливается посложнее - надо чтобы фабрика меток умела генерить многокусковые полилинии и полигоны из нескольких кусков (заодно и с дырками), пока что туда можно пихнуть только простой массив из координат точек. То есть опять же лечение возможно только на этапе загрузки (импорта) меток. Но не на этапе обновления исторических данных (в смысле конвертации из SML в SQLite). Это конечно самый главный тезис за то, чтобы уникальность не делать. Ну а в) в случае натягивания уникальности по паре полей (категория метки, имя метки) вообще не требует разруливания )), так как сразу по рукам - и всё )) Соответственно юзер может быть будет получать по рукам при сохранении метки после изменения её имени или её категории. Лично я за то чтобы забить и оставить возможность создавать одноимённые метки в одной категории в любом количестве, но мало ли у кого какие идеи возникнут...

(0010385) vdemidov (manager) 14-01-2013 12:55	Я тоже, против ограничений на именование меток. PS: Фабрика меток прекрасно умеет обрабатывать многокусковые полилинии и мультиполигоны.

(0010386) vasketsov (manager) 14-01-2013 13:19	>Фабрика меток прекрасно умеет обрабатывать Я писал про "генерить". Я вижу что там есть Count и список внутренностей. И даже сохраняю их. Но вот в TMarksDb.ReadCurrentMark я вижу только один массив для вызова FFactoryDbInternal.CreateMark (и соответственно один аргумент для массива в этой функции). Если же ты про то что надо юзать Create* без New - то они в TMarkFactory недоступны снаружи, в IMarkFactory и IMarkFactorySmlInternal их нет. Значит надо их вытаскивать (очевидно в IMarkFactorySmlInternal). Кроме того - всё равно придётся звать что-то типа VPolygon := FFactory.CreateLonLatPolygon(APoints, APointCount) - только для множества кусков.

(0010388) vdemidov (manager) 14-01-2013 13:54	Оно прекрасно хавает множество кусков. Только раздели куски при помощи CEmptyPoint и получишь мультиполигон с нужным количеством кусков. И оно в метку прекрасно сохранится. Вопросы будут только с эксортом в некоторые форматы.

(0010392) vasketsov (manager) 14-01-2013 23:25	Приаттачил SAS_SQLITE_MARKS_TEST.rar. В архиве: а) EXE-ха для игр по текущей версии репо + то что ещё моё не залито; б) актуальная официальная версия библиотеки sqlite3.dll; в) скрипт Marks.SLT.0.1.sql для создания БД. Файл sqlite3.dll надо положить рядом с EXE-хой. Так как я не обновляюсь ночнушками, я не знаю, эта же версия в ночнушке, или нет. Файл скрипта Marks.SLT.0.1.sql надо положить в подпапку DBMS (туда же, где лежат скрипты создания кэша тайлов для разных СУБД). Кроме этого надо в файле SASPlanet.ini в секции [MarkNewCategory] параметру DBFileName присвоить значение имени файла БД с расширением .sqlitedb. Например так: [MarkNewCategory] DefaultName=Новая категория AfterScale=3 BeforeScale=23 DBFileName=MarksTEST.sqlitedb В этом случае при загрузке саса из скрипта старые категории и метки (которые в файлах SML) трогаться не будут, а будет создана (или обновлена при необходимости) новая структура БД меток. Если БД пустая (самый первый раз) - версия 0. Версия в EXE указана как 1 - соответственно при открытии БД меток проверяется версия (хранящаяся внутри БД), и при небходимости структура обновляется скриптом. Поэтому скрипт так и зовётся. Это позволит в будущем прозрачно обновлять структуру БД при необходимости таких обновлений независимо от того, где и как будет храниться скрипт обновления структуры. Если БД уже есть и её версия соответствует EXE-хе - она не обновляется. Так что игровой комплект только первый раз запускается дольше обычного на несколько секунд, потом просто проверка версии - и всё. Оригинальная ночнушка (без моих правок) игнорирует параметр DBFileName (он там пустой). Файлы БД меток (их может быть один, а может быть несколько, в зависимости от настроек) по умолчанию находятся в папке с сасом. При тех настройках, при которых собрана EXE-ха, будет использоваться WAL, и в соответствии с мануалами SQLite оно работает только локально (не по сетке, у SQLite вообще якобы проблемы с работой через сеть), зато быстро. Так вот в режиме WAL будет 3 файлика: MarksTEST.sqlitedb MarksTEST.sqlitedb-shm MarksTEST.sqlitedb-wal В других режимах может быть один первый файлик, или другой набор. Но в любом случае если надо убить БД - надо просто удалить все эти файлы. При последующем запуске саса БД создастся из скрипта снова. Если верить мануалам - WAL доступен только начиная с версии SQLite 3.7.0. Кусок кода конвертации старых меток (SML) в новый формат (SQLITE) вырезан намеренно. Он до тупого прост (взять все категории и метки из старой БД и уронить в новую), так что его тестировать как раз бессмысленно. Фактически он ничем не отличается от многократного импорта меток из кучи разных KML. Намеренность такого вырезания обусловлена тем, что возможно что-нибудь ещё поменяется в структуре БД, так что возможно результаты игр с новой БД меток просто придётся убить при официальном выпуске доработки. Копирование данных из старой БД в новую (при такой конвертации) предполагается однократным (дабы не "париться" с дублями) и соответственно однонаправленным. Получение списка видимых меток выполняется по "окну" координат. И вполне быстро работает. По крайней мере меня скорость не напрягает, даже при работе только на голом кэше SQLite без внутреннего кэша на прямых SQL-запросах. Однако в форме менеджера меток при переключении между категориями тащатся из БД все метки этой категории. Так что не рекомендуется создавать сильно много десятков тысяч меток в одной категории. Также если в менеджере меток была выбрана такая тяжёлая категория - закрытие формы занимает некоторое время, так как надо освободить память (в старой версии кэш сохранялся в памяти и соответственно при прочих равных условиях без необходимости сохранения данных закрытие было бы быстрее). Зато как и предполагалось (для чего собственно всё и затевалось) - при сохранении изменений одной метки не сохраняется всё что можно в БД. То есть фактически время сохранения (импорта) в известной степени не зависит от размера базы меток, а зависит от количества изменений или вставок. Изменили одну метку - одна метка в БД и обновилась. Также как и предполагалось, даже голое сохранение меток в БД стало быстрее, и размер меньше (в принципе можно ещё более плотно утоптать, но это уже надо в сасе править другие места). Я гонял в качестве теста импорт покрытия ESRI, которе не так давно выкладывал в соответствующей теме на форуме. Это 57 файлов KMZ суммарным размером 13.5 МБ. Импорт в новую пустую БД в старом формате SML всех этих файлов враз в одну категорию занял 7 мин 40 с (плюс-минус несколько секунд), итоговый размер - 75.2 МБ. Импорт в SQLite занимает 3.5 минуты, итоговый размер - 44 МБ. В собранной EXE-хе нет поддержки многопользовательности, всегда один юзер 0 (это если вдруг кто полезет смотреть как БД устроена). Также нет мониторинга изменений из сторонних сасов (при запуске нескольких экземпляров с одной БД меток). Якобы SQLite имеет встроенную возможность мониторинга изменений, но я пока что с этим не разбирался. Также не реализованы счётчики производительности, так как старые были на чтение и запись БД целиком, а для SQLite они очевидно не подойдут, так как фактически эти процедуры (сохранения и чтения всей БД) пустые и ничего не делают (БД никогда не читается целиком и не пишется целиком). В общем надо какие-то другие счётчики забацать, а какие реально нужны - хз. Структура новой БД предусматривает импорт и хранение как треков с разрывами, так и многокомпонентных полигонов с дырками. Где-то в сасе немного недоделано, например импорт KML можно сделать как Виктор выше посоветовал через CEmptyDoublePoint - и тогда полигончик или трек будет из нескольких кусков. Где-то совсем глухо, например всё что касается дырок в полигонах. Тем не менее на будущее это сразу сделано. Также сделал возможность хранить координаты в BLOB-е в разных форматах, чтобы можно было потенциально импортировать/экспортировать треки с сохранением всех данных (например кроме координат ещё и высоты, скорости, временА и т.п.). Также предусмотрена возможность сохранять всякие разные поля объектов в отдельных полях для метки, типа даты метки или источника метки или описания прибора, откуда оно импортировано, в произвольном формате, именно для целей максимально полного импорта-экспорта меток. В этом отношении SQLite с его слабой типизированностью полей исключительно удобен ))) В общем, играйтесь на здоровье.

(0010410) vasketsov (manager) 17-01-2013 09:57	SAS_MARKS_SQLITE.rar - версия с возможностью выполнения процедуры импорта категорий и меток из старой БД. В новом архиве те же самые файлы (в смысле описания, EXE-ха поменялась). Режим импорта при старте саса указывается опять же в поле DBFileName символом потокового копирования. То есть в ini-шке надо указать что-то типа: [MarkNewCategory] DefaultName=Новая категория AfterScale=3 BeforeScale=23 DBFileName=>MarksInSQLite3.sqlitedb В этом случае будут импортированы данные из старой БД в новую другую (незвисимо от того, создана она только что или уже существовала до этого). После завершения процедуры импорта символ '>' после закрытия саса удалится сам (защита дурака от дурака, то есть сохранится "DBFileName=MarksInSQLite3.sqlitedb" и при следующем запуске импорт не запустится). Так как изначально сас запускается с пустым значением DBFileName - импортировать можно данные только из старой БД в формате SML. Это в общем-то не сильно сложно модифицировать, чтобы можно было импортировать категории и метки и из сторонних баз (SML или .sqlitedb). Ну и очевидно глупо указывать там что-то типа "DBFileName=>" - импорт в обратную сторону не сработает, так как исходная и целевая БД одинаковы (дефлотные SML-ки). Забыл ещё отметить, что если значение параметра DBFileName пустое - ничего не изменится. То есть даже приаттаченная EXE-ха по-прежнему работает со старыми категориями и метками в формате SML. Ещё немного пописал внутренний кэш, чтобы при чтении меток чуток меньше памяти сжиралось на категории. Ну и массовые вставки меток оптимизировал. В остальном всё то же самое, что и было. Цель конкретно этого аттача - чтобы проверили, как конвертируется база с метками. Вернее это не конвертирование, так как старая БД (файлы SML) остаётся как есть. По сути это импорт категорий и меток. Так как имена категорий уникальны - при повторном импорте им не поплохеет, лишние просто не вставятся. А вот ввиду отсутствия уникальности по именами меток, метки при повторном импорте тупо продублируются. Так что как и предполагалось - перенос должен случиться за один старт саса. Поскольку процедуры вычищения лишних дублей не предусмотрено - база конечно загадится. Ах ну да, ещё счётчиков понаделал с избытком. Половину их надо по идее отнести будет к TMarksSystem или просто убить. Если ничего страшного не найдёте - завтра-послезавтра буду заливаться.

(0010411) zed (manager) 17-01-2013 10:15 edited on: 17-01-2013 10:20	Если САС не находит скрипт Marks.SLT.0.1.sql, то выдаётся малопонятный ассерт (аттач). И не понятно что и чего вообще. И предлагаю сделать папку MarksSQLite и положить туда по-умолчанию этот скрипт, а не в DBMS. В той же папке (MarksSQLite) по-умолчанию хранить и файлы БД с метками. Чтобы всё было в одном месте.

(0010412) vdemidov (manager) 17-01-2013 10:42 edited on: 17-01-2013 10:43	>Так как имена категорий уникальны В SML это совсем не обязательно, вполне можно иметь несколько категорий с одинаковыми именами PS: Добиться этого не очень просто, но можно.

(0010413) vasketsov (manager) 17-01-2013 10:48	>предлагаю сделать папку MarksSQLite Так в сасе же вроде бы можно указать папку для БД меток. По крайней мере в TGlobalState.Create есть что-то типа FMarksDbPath := TPathConfig.Create('PrimaryPath', '.', FBaseDataPath); Логичнее тогда просто без подпапки DBMS сделать - и получится что если FMarksDbPath указано - значит там же рядом и скрипт лежит и база. То есть в ini-шке сейчас по умолчанию: [PATHtoMARKS] PrimaryPath=. А можно указать при необходимости что-то типа: PrimaryPath=.\SQLiteMarks Или ты ещё хочешь глубже этой настройки подпапку MarksSQLite захардкодить? >малопонятный ассерт Ага. Чё-нить щас придумаем.

(0010414) zed (manager) 17-01-2013 10:52	>Или ты ещё хочешь глубже этой настройки подпапку MarksSQLite захардкодить? Нет, у тебя сейчас захардкожено местонахождение файла скрипта sql, вот я и предлагаю, вынести это в настройки и сделать папку по-умолчанию MarksSQLite.

(0010415) zarius (reporter) 17-01-2013 10:54	Планируется ли поддержка многопользовательности? Если да, то было бы хорошо в САС добавить обновление меток из базы по кнопке/таймеру.

(0010416) vasketsov (manager) 17-01-2013 11:15	>вполне можно иметь несколько категорий с одинаковыми именами Ну да, например переименованием )). Но я не придумал глубокий смысл для этого. При создании-редактировании меток в выпадающем списке по имени их не отличить. В менеджере меток тоже искаться и переключаться между ними несколько тупо. Разве что часть меток в одной категории чтобы имела одну настройку видимости по зумам, а часть - другую, но это красивее реализуется "вложеными" категориями. зы. А при импорте метки просто залетят в категорию по её имени. Даже если их будет мильён дублирующихся. >захардкожено местонахождение файла скрипта sql Там щас захардкожено буквально вот так: VScriptFileName := IncludeTrailingPathDelimiter(FBasePath.FullPath) + 'DBMS\' + 'Marks.SLT.' + Соответственно настройка PrimaryPath учитывается. SLT - просто аббревиатура для SQLite (отличная от всех остальных СУБД). >сделать папку по-умолчанию MarksSQLite А ну вот тогда значит надо будет убить 'DBMS\' отсюда и сделать чтение настройки с другим значением по умолчанию: FMarksDbPath := TPathConfig.Create('PrimaryPath', '.\MarksSQLite', FBaseDataPath); (Но) Тогда в существующие ini-шки оно не залетит (там уже есть "PrimaryPath=. ") - (зато) будет без хардкодинга и однообразно. >Планируется ли поддержка многопользовательности? Если коротко - то "да". Я совершенно спокойно работал с БД из SQLite Maestro одновременно с сасом. Максимум на что можем налететь - на какие-нибудь необходимые тонкие настройки сессии, к изменению структуры БД это не приведёт. Эксклюзивная блокировка БД включается только на время обновления структуры БД (если такое обновление необходимо). Если менее коротко - то вы походу путаете многопользовательность с мониторингом изменений в БД. Мониторинг также планируется, и струкрута под него сделана. Надо только чётко понять, для чего включать мониторинг (например для точек, для категорий), а для чего - нет (например для настроек видимости по зумам). Ну и 99% что сам пользователь свои изменения не мониторит - значит два саса, запущенные под одним и тем же юзером, смогут обмениваться данными только лишь прямо перечитывая их из БД. В любом случае запись в БД возможна из нескольких сасов. Если ещё менее коротко - на это есть отдельная тема.

(0010417) vasketsov (manager) 17-01-2013 14:28	Подменил EXE-ху в аттаче SAS_MarksSQLite.rar. Значение по умолчанию для пути к меткам сделано '.\MarksSQLite'. При обломах с обновлением структуры 2 проверки кидают (отлавливаемые) исключения (будет сообщение при загрузке): а) EXE слишком старая для такой БД (сделано на будущее) б) скрипт для обновления не нашёлся. Если облом - в менеджере меток будет светиться панелька, что БД вся такая недоступная. А теперь инструкция для чайников. Нечайники пропускают ))). Итого чтобы корректно обновиться с этой EXE-хой, надо: а) в ini-шке переименовать путь до меток например так: [PATHtoMARKS] PrimaryPath=.\MarksSQLite б) создать указанную папку (в примере - подпапку MarksSQLite) в) перенести туда файлы Categorymarks.sml и marks.sml (настройка пути к меткам одна, и если этот шаг не сделать, то старые метки просто не найдутся) (зы. пока что ничего сврхъестественного, указание пути к меткам было доступно и ранее, более того, на всех этих шагах а)-г) можно указать и другое имя папки, просто тут указано значение по умолчанию, и если вдруг ini-шка пропадёт - подхватится именно это значение, и даже более того - старые БД с метками работают даже в папке MarksSQLite). г) в папку MarksSQLite сложить файл Marks.SLT.0.1.sql. д) в папку с сасом сложить EXE-ху и sqlite3.dll е) в ini-шке указать имя файла новой БД меток в виде: [MarkNewCategory] DBFileName=>MarksDB.sqlitedb (зы. такая запись приведёт к тому, что при следуюещм запуске саса будет выполнено копирование существующих категорий и меток в новую БД в новом формате, если её нет - она будет создана; если копировать старые метки не надо - пишем просто DBFileName=MarksDB.sqlitedb). е) -Поехали! запускаем сас, ждём десяток-другой секунд (минуту?) в зависимости от количества меток. После того как сас окончательно запустится - идём в менеджер меток, смотрим что получилось, в зависимости от результата или повторяем миграцию (закрыв сас и удалив файлы новой БД руками), или архивируем старые SML-ки для потомков в отдельную папочку на всякий пожарный.

(0010421) vasketsov (manager) 18-01-2013 19:32	Раз больше ничего не нашли - я тогда приаттаченный архивчик оставляю, чтобы из него скрипт и DLL взять, EXE соответственно можно выкинуть, но специально переархивировать лениво. Так что как отпадёт в нём потребность - убивайте. Залитое в репо будет соответствовать скрипту в архиве, там ничего не поменялось.

(0010422) vasketsov (manager) 19-01-2013 11:29	Поскольку у нашего местного идиота имеем очередное обострение синдрома вахтёра - я к сожалению так и не смогу залить песпотерьный импорт из внешней БД SQLite и беспотерьный экспорт во внешнюю БД SQLite через менеджер меток. You are no longer a member of SAS.Team. К сожалению.

(0010434) zarius (reporter) 21-01-2013 10:38	Поставил - немного потестил - почти все замечательно! Что получилось: 1. Несколько САСов работают с одной базой без проблем, причем в т.ч. на запись, при этом в остальных САСах метки обновляются по "Hide all placemarks" (особенно удобно после установки на эту команду хоткея) 2. Базу меток можно выносить на сетевое хранилище, возможно в этом случае есть проблемы при одновременном доступе - не смотрел, последовательный доступ на чтение/запись из разных САСов проходят корректно. 3. Реакции на одновременное изменение/удаление меток и прочие действия понятны и предсказуемы. Что не получилось: При добавлении новой категории в одном из САСов - в этом САСе категория появляется и метки корректно отображаются, в других же САСах в менеджере эта категория не появляется, более того при обновлении меток - метки с карты исчезают - в менеджере они есть, но заставить их отобразиться на карте можно только с помощью перезапуска САСа. Итого: Спасибо огромное за проделанную работу - давно ждал чего то подобного!

(0010435) Tolik (reporter) 21-01-2013 11:04	Так будет эта фича в основном коде или нет? И в чём, собствено, проблема?

(0010436) zarius (reporter) 21-01-2013 12:11	Кстати, еще категория удаляется менеджером только с 3го раза.

(0010437) zed (manager) 21-01-2013 12:37 edited on: 21-01-2013 12:38	>Так будет эта фича в основном коде или нет? Она там была непродолжительное время, но затем весь код был удалён. Кроме того, vasketsov теперь сможет вносить изменения в код, только через пул реквесты. >Changeset: 6975 (cf73620c9a9f) revert commits of vasketsov >User: Viktor Demidov <[email protected]> >Date: 2013-01-19 00:05:06 +0200 (2 days) >Parent: 6974 (e9781e8cfd9d) 1481: новые файлы >Child: 6976 (a4a092a77fae) Исправление опечаток. Спасибо vasketsov В общем, повторилась ситуация с panoramio и не стоит ждать скорого появления этой (и той) фичи в САС.

(0010438) Tolik (reporter) 21-01-2013 12:41	Ага, это я видел. Но не понял почему.

(0010439) zed (manager) 21-01-2013 12:48	Это уже вопрос к vdemidov. Может ему стиль программирования не понравился (был там мега-юнит в 3500 строк кода) и он решил принять такие радикальные меры?

(0010440) vasketsov (manager) 21-01-2013 14:44	>в других же САСах в менеджере эта категория не появляется Потому что категории кэшируются, а метки - нет. А чтобы "передёрнуть" кэш - остальные сасы должны как-то сообщить об изменениях. Это в общем-то легко реализуемо и предполагалось (замечу, несмотря на то, что лично мне это неактуально, так как сас у меня ровно один), достаточно после окончательного коммита метки в БД "капнуть" в лог, а соответственно по Sync-у сас нюхает этот лог и при необходимости сбрасывает признак актуальности кэша и (или) поднимает признак необходимости перерисовки меток и(или) категорий. >vasketsov теперь сможет вносить изменения в код, только через пул реквесты Меня vasketsov уполномочил передать, что он не сможет пользоваться такой возможностью по вполне понятным (я бы даже от себя добавил, очевидным) техническим причинам. Не говоря уже о том, чтобы решение о том, принимать или нет пулреквесты принимал человек, после коммитов которого проект было дело даже не собирался. Это просто нонсенс. Ему самому пора через пулреквесты работать. Это и называется "синдром вахтёра". Заливка например ODBC с тайлохралищем в СУБД (чтобы без DLL) в сас представляется в таком аспекте иллюзорной на все 146%. Впрочем мне реально параллельно. Я уже сделал у себя в том числе и фильтрацию зумов (1337, остались только экспорты, которыми я практически никогда не пользуюсь, когда будете тут это делать - мне не жалко, выдам как сделал сам). Теперь лично меня сас почти устраивает полностью. Отзывать свои правки и в частности лицензию vsagps я не буду, менять интерфейс DLL тоже, так как я понимаю, что народ, который этим пользуется, не должен страдать (сохранение функциональности для меня приоритетно, ну а что сломает "неназываемый" - ну значит его и пинайте). Надо чётко понимать, что "наказал" этим он не меня. Опять же так как изначально реализация доработок "по методу zed-а" предполагает реализацию того что надо именно программисту лично - после реализации того что сейчас на мне висит, я бы всё равно мог только ошибки исправлять, новых больших серьёзных доработок я пока для себя не вижу (хотя возможно они бы и появились). Вот и выходит, что обе крайности технически нереализуемы: большие сложные вещи мне проще сделать для себя и не согласовывать всякую фигню с непонятно какими судьями, считающими возможным ответить что-то типа "а, оно сломано пару лет назад, и восстанавливать я это не собираюсь". Нет никакой гарантии, что то, что я сделаю, снова не будет сломано просто потому, что у кого-то не хватило ума в этом разобраться. В такой ситуации "метод zed-а" перестаёт работать, так как у программиста теряется стимул, так как есть "вахтёр", который и сам не делает, и другим не даёт. Ну а соответственно мелкие доработки и мелкие багофиксы тем более глупо мне в таком режиме делать. Достаточно всего лишь долго не отвечать на пулреквест (причём такое уже было) - чтобы с полным правом требовать его переделки в соответствии с изменениями в репо. >не стоит ждать скорого появления Разумеется. Вечный рефакторинг рефакторинга рефакторинга куда важнее доработок, запланированных на 2020 год например )). >стиль программирования В таком случае ему пора отвлечься от переписывания ошибок предыдущих рефакторингов и все-таки родить Священное Писание типа "Стиль программирования для саса: Евангелие от Виктора". Пока это изменчиво даже в рамках одного релиза (и двух сообщений в багтрекере через одно сообщение)))) - это всё не более чем охота на ведьм и прочая схоластика типа поиска чертей в напёрстке. >мега-юнит в 3500 строк кода Ну что ж не сказали сразу ))) я б как в перле упаковал бы его строк в 5-6 )))) В заключение отмечу, что я никуда не пропадаю и по мере наличия свободного времени по-прежнему доступен для контактов, советов и комментариев по существу. Дополнительно выражу благодарность программистам (и не только), чьими трудами я пользовался, "обменивая" их на свои. Персоналии я называть не буду, каждый и так знает, в рамках каких "подзадач" мы с ним(и) пересекались, создавая что-то новое, интересное и полезное.

(0010523) zarius (reporter) 08-02-2013 08:33	появился вопрос: как преобразовать координаты из полей m_lon, m_lat в координаты отображаемые SAS? например в SAS точка: N58°35'41,37" E49°40'53,04" в БД SQLite точка: 698892855 592577482

(0010524) vasketsov (manager) 08-02-2013 09:34	Поделить на 0xB60000 aka $B60000

(0010525) zarius (reporter) 08-02-2013 11:23	>Поделить на 0xB60000 aka $B60000 Спасибо!

(0010545) zarius (reporter) 11-02-2013 13:16	заранее извиняюсь за нескромность: можно ли в рамках данной сборки реализовать хотелку 0000193 (Drag&Drop в окне управления метками) и насколько это трудоемко?

(0010546) vasketsov (manager) 11-02-2013 14:26	Давайте обсуждать доработки в тикетах, им посвящённых.

(0010547) zarius (reporter) 11-02-2013 15:19	Согласен, что получается оффтоп, но: - продолжать обсуждение в тикете 0000193 смысла не вижу, т.к. реализация данной хотелки нужна именно в Вашей сборке (метки в SQLite); - при создании нового тикета - его скорее всего тут же закроют - ибо дубль. Если только в новом тикете конкретно указывать, что хотелка для сборки с метками в SQLite, но тогда еще большая путаница получиться. Не совсем понятная ситуация...

(0010548) vasketsov (manager) 11-02-2013 23:25	>продолжать обсуждение в тикете 0000193 смысла не вижу, т.к. реализация данной хотелки нужна именно в Вашей сборке (метки в SQLite); Побойтесь Бога, там даже не 2050-й год стоит ))). Так что доработка актуальна чуть выше плинтуса и для основной ветки. >при создании нового тикета Потому что есть 0000193. Туда и идите. И не надо писать ничего про "сборку". Где когда надо - тогда там и будет. Я точно также вижу, что тут висит несделанное, и точно также определяю для себя, чего мне лично более надо, а чего - нет.

Users who viewed this issue
User List	Anonymous (7755x), QDeathNick (1x), SlavutichRED (4x), noxicus (1x), lovegrach (2x), Oldest_Yeti (1x), hrucker (1x), gamuer (1x), tiburon (2x), zarius (2x), Parasite (1x), zed (2x)
Total Views	7773
Last View	21-11-2024 17:32

Issue History
Date Modified	Username	Field	Change
09-08-2012 16:04	Parasite	New Issue
09-08-2012 17:19	zed	Note Added: 0008237
09-08-2012 19:58	Papazol	Note Added: 0008238
10-08-2012 03:26	Parasite	Note Added: 0008242
10-08-2012 03:26	Parasite	Note Edited: 0008242	View Revisions
10-08-2012 05:58	Tolik	Note Added: 0008245
10-08-2012 05:58	Tolik	Status	new => acknowledged
10-08-2012 06:30	vdemidov	Note Added: 0008246
10-08-2012 06:58	Fetser	Note Added: 0008247
10-08-2012 07:15	vdemidov	Note Added: 0008248
10-08-2012 07:20	Fetser	Note Added: 0008249
10-08-2012 07:28	Parasite	Note Added: 0008250
10-08-2012 07:32	vdemidov	Note Added: 0008251
10-08-2012 07:35	Papazol	Note Added: 0008252
10-08-2012 07:36	Tolik	Note Added: 0008253
10-08-2012 07:48	vdemidov	Note Added: 0008255
10-08-2012 07:50	vdemidov	Note Added: 0008256
10-08-2012 07:57	vdemidov	Note Added: 0008257
10-08-2012 08:19	Parasite	Note Added: 0008258
10-08-2012 08:20	Parasite	Note Edited: 0008258	View Revisions
10-08-2012 08:32	vdemidov	Note Added: 0008259
10-08-2012 08:32	vdemidov	Note Edited: 0008259	View Revisions
10-08-2012 08:35	Parasite	Note Added: 0008260
10-08-2012 08:38	vdemidov	Note Added: 0008261
10-08-2012 09:16	vasketsov	Note Added: 0008262
10-08-2012 09:27	Parasite	Note Added: 0008263
10-08-2012 09:31	Fetser	Note Added: 0008264
10-08-2012 09:31	Tolik	Note Added: 0008265
10-08-2012 09:47	vasketsov	Note Added: 0008266
10-08-2012 09:53	Tolik	Note Added: 0008267
10-08-2012 09:53	vasketsov	Note Added: 0008268
10-08-2012 09:56	vasketsov	Note Added: 0008269
10-08-2012 09:56	Fetser	Note Added: 0008270
10-08-2012 10:05	Parasite	Note Added: 0008271
10-08-2012 10:05	Tolik	Note Added: 0008272
10-08-2012 10:06	Parasite	Note Edited: 0008271	View Revisions
10-08-2012 10:08	Parasite	Note Added: 0008273
10-08-2012 10:16	vasketsov	Note Added: 0008274
10-08-2012 10:16	Tolik	Note Added: 0008275
10-08-2012 10:22	Fetser	Note Added: 0008276
10-08-2012 10:25	Tolik	Note Added: 0008277
10-08-2012 10:32	vasketsov	Note Added: 0008278
10-08-2012 13:03	vasketsov	Note Added: 0008282
10-08-2012 13:05	vasketsov	Note Edited: 0008282	View Revisions
10-08-2012 13:17	vdemidov	Note Added: 0008283
11-08-2012 04:56	Parasite	Note Added: 0008304
11-08-2012 05:02	Tolik	Note Added: 0008305
11-08-2012 05:36	Parasite	Note Added: 0008314
11-08-2012 05:37	Tolik	Note Added: 0008315
12-08-2012 12:21	gpsMax	Relationship added	related to 0001039
13-08-2012 13:17	zarius	Note Added: 0008425
13-08-2012 13:36	zarius	Note Edited: 0008425	View Revisions
13-08-2012 13:44	zarius	Note Edited: 0008425	View Revisions
13-08-2012 13:49	zed	Note Added: 0008427
14-08-2012 09:12	zarius	Note Added: 0008448
14-08-2012 09:18	zarius	Note Edited: 0008448	View Revisions
14-08-2012 09:20	zed	Note Added: 0008449
14-08-2012 10:18	zarius	Note Added: 0008450
14-08-2012 10:28	zed	Note Added: 0008452
14-08-2012 11:35	vasketsov	Note Added: 0008473
14-08-2012 12:10	zarius	Note Added: 0008489
14-08-2012 12:12	zarius	Note Edited: 0008489	View Revisions
14-08-2012 13:42	Parasite	Note Added: 0008500
30-12-2012 20:39	vasketsov	Relationship added	related to 0001217
30-12-2012 21:35	vdemidov	Relationship replaced	child of 0001217
31-12-2012 04:57	Fed	Note Added: 0010279
04-01-2013 15:28	vasketsov	Note Added: 0010317
04-01-2013 15:29	vasketsov	Assigned To	=> vasketsov
04-01-2013 15:29	vasketsov	Status	acknowledged => assigned
14-01-2013 12:41	vasketsov	Note Added: 0010382
14-01-2013 12:55	vdemidov	Note Added: 0010385
14-01-2013 13:19	vasketsov	Note Added: 0010386
14-01-2013 13:54	vdemidov	Note Added: 0010388
14-01-2013 22:07	vasketsov	File Added: SAS_SQLITE_MARKS_TEST.rar
14-01-2013 23:25	vasketsov	Note Added: 0010392
17-01-2013 09:29	vasketsov	File Deleted: SAS_SQLITE_MARKS_TEST.rar
17-01-2013 09:57	vasketsov	Note Added: 0010410
17-01-2013 09:57	vasketsov	File Added: SAS_MARKS_SQLITE.rar
17-01-2013 10:10	zed	File Added: Assert.jpg
17-01-2013 10:15	zed	Note Added: 0010411
17-01-2013 10:20	zed	Note Edited: 0010411	View Revisions
17-01-2013 10:42	vdemidov	Note Added: 0010412
17-01-2013 10:43	vdemidov	Note Edited: 0010412	View Revisions
17-01-2013 10:48	vasketsov	Note Added: 0010413
17-01-2013 10:52	zed	Note Added: 0010414
17-01-2013 10:54	zarius	Note Added: 0010415
17-01-2013 11:15	vasketsov	Note Added: 0010416
17-01-2013 14:02	vasketsov	File Deleted: SAS_MARKS_SQLITE.rar
17-01-2013 14:02	vasketsov	File Added: SAS_MarksSQLite.rar
17-01-2013 14:28	vasketsov	Note Added: 0010417
18-01-2013 19:32	vasketsov	Note Added: 0010421
19-01-2013 11:29	vasketsov	Note Added: 0010422
21-01-2013 10:38	zarius	Note Added: 0010434
21-01-2013 11:04	Tolik	Note Added: 0010435
21-01-2013 12:11	zarius	Note Added: 0010436
21-01-2013 12:37	zed	Note Added: 0010437
21-01-2013 12:37	zed	File Deleted: Assert.jpg
21-01-2013 12:37	zed	Note Edited: 0010437	View Revisions
21-01-2013 12:38	zed	Note Edited: 0010437	View Revisions
21-01-2013 12:38	zed	Note Edited: 0010437	View Revisions
21-01-2013 12:41	Tolik	Note Added: 0010438
21-01-2013 12:48	zed	Note Added: 0010439
21-01-2013 14:44	vasketsov	Note Added: 0010440
08-02-2013 08:33	zarius	Note Added: 0010523
08-02-2013 09:34	vasketsov	Note Added: 0010524
08-02-2013 11:23	zarius	Note Added: 0010525
11-02-2013 13:16	zarius	Note Added: 0010545
11-02-2013 14:26	vasketsov	Note Added: 0010546
11-02-2013 15:19	zarius	Note Added: 0010547
11-02-2013 23:25	vasketsov	Note Added: 0010548
13-02-2013 11:03	vasketsov	Project	SAS.Планета => SACS.Планета
13-02-2013 11:08	vasketsov	Status	assigned => resolved
13-02-2013 11:08	vasketsov	Resolution	open => fixed
13-02-2013 11:09	vasketsov	File Deleted: SAS_MarksSQLite.rar
09-08-2013 15:00	vasketsov	Fixed in Version	=> 130803
09-08-2013 15:13	vasketsov	Status	resolved => closed

SASGIS