SASGIS - SAS.Планета
View Issue Details
0001217SAS.ПланетаРефакторингpublic14-03-2012 18:1919-02-2015 10:11
vasketsov 
 
normalminorN/A
confirmedopen 
WindowsVistaUltimate
110418 
29xxxx 
0001217: Избавиться от MidasLib
Избавиться от использования датасетов при работе с sml файлами.
библиотеки
parent of 0001481closed vasketsov SACS.Планета Переделка хранилища меток 
parent of 0000304resolved zed SAS.Планета Импорт меток из файлов marks.sml и categorymarks.sml 
child of 0002107resolved zed SAS.Планета sml файлы не по стандарту XML 
zip sml_load.zip (3,127,534) 07-09-2014 17:43
http://www.sasgis.org/mantis/file_download.php?file_id=1766&type=bug
Issue History
14-03-2012 18:19vasketsovNew Issue
14-03-2012 19:31vdemidovNote Added: 0006103
14-03-2012 19:50vasketsovNote Added: 0006104
14-03-2012 20:15zedNote Added: 0006105
14-03-2012 20:25vdemidovNote Added: 0006106
14-03-2012 20:30vasketsovNote Added: 0006107
14-03-2012 20:35vdemidovNote Added: 0006108
14-03-2012 20:41vdemidovNote Added: 0006109
22-03-2012 09:59gpsMaxTag Attached: библиотеки
23-03-2012 19:26vdemidovStatusnew => confirmed
23-03-2012 19:26vdemidovTarget Version => 26xxxx
23-03-2012 19:26vdemidovSummaryMidasLib => Избавиться от MidasLib
23-03-2012 19:26vdemidovDescription Updatedbug_revision_view_page.php?rev_id=3112#r3112
09-08-2012 06:53vdemidovProduct Version.Nightly => 110418
30-12-2012 20:39vasketsovRelationship addedrelated to 0001481
30-12-2012 20:47vasketsovNote Added: 0010270
30-12-2012 20:47vasketsovTag Attached: SQLite
30-12-2012 21:34vdemidovNote Added: 0010273
30-12-2012 21:35vdemidovRelationship replacedparent of 0001481
30-12-2012 21:35vdemidovNote Added: 0010274
30-12-2012 22:15vasketsovNote Added: 0010275
30-12-2012 22:15vasketsovTag Detached: SQLite
30-12-2012 22:17vasketsovNote Edited: 0010270bug_revision_view_page.php?bugnote_id=10270#r5026
30-12-2012 22:35vdemidovNote Added: 0010276
30-12-2012 22:35vdemidovRelationship addedparent of 0000304
30-12-2012 23:09vasketsovNote Added: 0010277
31-12-2012 16:44vdemidovNote Added: 0010287
31-12-2012 18:39vasketsovNote Added: 0010288
07-09-2014 17:43zedFile Added: sml_load.zip
07-09-2014 17:59zedNote Added: 0014611
07-09-2014 18:41vdemidovNote Added: 0014615
07-09-2014 18:47zedNote Added: 0014616
07-09-2014 18:48zedNote Edited: 0014616bug_revision_view_page.php?bugnote_id=14616#r6252
07-09-2014 19:28vdemidovNote Added: 0014619
07-09-2014 19:48vdemidovNote Edited: 0014619bug_revision_view_page.php?bugnote_id=14619#r6254
07-09-2014 20:09zedNote Added: 0014620
07-09-2014 20:18zedNote Added: 0014621
07-09-2014 20:45vdemidovNote Added: 0014622
19-02-2015 05:28zedRelationship addedchild of 0002107
19-02-2015 07:57vasketsovNote Added: 0015282
19-02-2015 10:11vdemidovNote Added: 0015284
19-02-2015 10:11vdemidovTarget Version26xxxx => 29xxxx

Notes
(0006103)
vdemidov   
14-03-2012 19:31   
Помнится раньше были проблемы при запуске чистой версии без созданных sml файлов.
(0006104)
vasketsov   
14-03-2012 19:50   
Что без sml при запуске, что с ними - отклонений в работе меток не нашёл.
Голосую, убить! (C) мультфильм "Остров сокровищ".
(0006105)
zed   
14-03-2012 20:15   
Changeset: 3857 (f4898e5ea94c) Вернул MidasLib после слишком рьяной чистки Zed'а, так как без него требует наличия midas.dll
User: Viktor Demidov <[email protected]>
Date: 2011-07-26 10:50:15 +0300 (7 months ago)
(0006106)
vdemidov   
14-03-2012 20:25   
А, точно. Совсем забыл. А вообще нужен ридер и врайтер для sml файлов, что бы вообще отказаться от датасетов и midas
(0006107)
vasketsov   
14-03-2012 20:30   
Может MidasLib убить вместе с sml? Ну конечно не прямо сейчас, а чуть погодя?
(0006108)
vdemidov   
14-03-2012 20:35   
В том то и дело, что хочется это сделать плавно. То есть, сначала нужно сделать возможность выбора движка для хранения меток, а уж потом замена дефолтного с sml на что-то более современное
(0006109)
vdemidov   
14-03-2012 20:41   
А еще перед революционными изменениями нужно сделать нормальный экспорт-импорт с минимальными потерями информации.
(0010270)
vasketsov   
30-12-2012 20:47   
(edited on: 30-12-2012 22:17)
<тут был оффтопик>

(0010273)
vdemidov   
30-12-2012 21:34   
К этому топику SQLite никакого отношения не имеет.
(0010274)
vdemidov   
30-12-2012 21:35   
И кстати, пока этот рефакторинг не будет выполнен, ни о каких переделках базы меток речь идти не будет.
(0010275)
vasketsov   
30-12-2012 22:15   
>К этому топику SQLite никакого отношения не имеет
Хм. Пожалуй да, это я погорячился, ща удалю ссылочку.

>пока этот рефакторинг не будет выполнен, ни о каких переделках базы меток речь идти не будет
Ты уже праздновать начал? ))))
Этот пункт никакого отношения не имеет к меткам не в SML.

Этот пункт надо просто закрыть и вообще не делать. После отказа от SML (а для этого надо сделать метки не в SML, и процедура сохранения собственно и будет процедурой экспорта aka конвертирования SML-XXX) через пару релизов вычистить метки в SML - и всё спокойно умрёт своей смертью.
(0010276)
vdemidov   
30-12-2012 22:35   
Вот сделай импорт-экспорт в sml без потерь данных, а потом будем обсуждать что делать дальше.
(0010277)
vasketsov   
30-12-2012 23:09   
>сделай импорт-экспорт в sml без потерь данных
Зачем?
Достаточно забацать модель данных + сделать настройку откуда читать метки + сделать настройку куда сохранять метки + добавить сохранение прочтённых меток не в SML (а в БД) и чтение их оттуда.
Сделать копирование меток из БД в SML без потери нереально по определению, потеря информации будет обязательно, так как полей и данных будет больше, чем сейчас.

Если я правильно понял - достаточно переписать:
TMarksSystem(IMarksSystem) в u_MarksSystem
TMarksDb(IMarksDb) в u_MarksDb
там правда болтается IMarksDbSmlInternal, но принципиально он ничего не портит, я не вижу связи снаружи этих интерфейсов с SML. Может конечно плохо искал ((. Все интерфейсы из i_MarksDbSmlInternal привязки к SML не имеют. Пока-что не вижу проблем в имплементации выше уровня SML.

Разумеется, если бы был интерфейс именно для работы напрямую с метками в хранилище (прочитать/сохранить/удалить одну/кучку/по Zoom+Rect, и т.п.), было бы проще, оно бы прямо на SQL ложилось бы, но в общем-то и имеющегося вроде бы достаточно.
(0010287)
vdemidov   
31-12-2012 16:44   
>Сделать копирование меток из БД в SML без потери нереально по определению, потеря информации будет обязательно, так как полей и данных будет больше, чем сейчас.
Ну-ну. При том что сейчас база хранится именно в sml это реально по определению. В общем, любые изменения нарушающие совместимость с метками старых версий вводи только в отдельной ветке или я их буду откатывать. Когда можно будет переключаться между разными движками на лету, тогда и вольем в основную ветку.
(0010288)
vasketsov   
31-12-2012 18:39   
>это реально по определению
Хм. Или "без потери данных" у тебя какой-то свой смысл имеет, или одно из двух. Достаточно мне добавить ОДНО поле speed для точек трека - и уже не будет конвертации SQL-SML-SQL без потери точности ))). Вкуриваешь?

>любые изменения нарушающие совместимость
Давай ты для начала начнёшь с себя? Пока что из всех кто приложил лапу, именно от тебя больше всего ситуаций, когда что-то стороннее отваливается, а восстанавливать ты даже не собираешься. Так что в очередной раз желаю повзрослеть и в будущем году уважительнее относиться к чужому труду, как минимум перед доработкой хотя бы простым поиском проверить, что будет если например contenttype пописать, и т.п. После моих доработок стороннего отваливается всегда ровно ноль, у меня политика такая, и её тебе же желаю оценить и придерживатьс её.

>Когда можно будет переключаться между разными движками на лету
Я эту возможность постулировал несколько сообщений назад, одень глаза и утри ЧСВ.
(0014611)
zed   
07-09-2014 17:59   
Провёл некоторые тесты (в аттаче) и пришёл к выводу, что в Delphi2007 MidasLib работает быстрее, чем парсинг xml (проверял на либах Alcinoe и OXml). В XE2 быстродействие примерно одинаковое и опять же, не в пользу парсеров xml.

Плюс ко всему, установлено, что загрузка меток через простой LoadFromStream работает быстрее, чем тот огород с ручной загрузкой XML в память, который сейчас есть. Надо будет пофиксить.

Ещё плюс в копилку - если использовать бинарный формат хранения датасета, то скорость загрузки возрастает в 10 раз (!) и рвёт все парсеры xml ещё на старте. Естественно, в SAS такой ошеломительной скорости получить не получится, ввиду неоптимального доступа к данным уже после загрузки меток в память (см. 0002462), но и то хлеб. Ожидаемый прирост в скорости, где-то на треть.

Ввиду вышесказанного, предлагаю от MidasLib ни в коем случае не избавляться (но иметь в виду "небольшой" баг в XE2..XE5), а наоборот, добавить настроек для выбора формата хранения xml(ansi)/xml(utf8)/bin(utf8), чтобы при желании можно было ускорить загрузку меток, отказавшись от текстового формата. Так как у нас теперь есть нормальный экспорт/импорт в sml, то всегда можно получить текстовый бекап меток.
(0014615)
vdemidov   
07-09-2014 18:41   
А ты проверял другие DOM или SAX парсеры? Тут нужно именно SAX-парсер использовать.
(0014616)
zed   
07-09-2014 18:47   
(edited on: 07-09-2014 18:48)
Именно SAX использовал. Качни архив, посмотри в сорцы. OXml взял спецом, потому как на родном сайте уж очень её хвалили за скорость. По их тестам обгоняет Alcinoe, по моим - обгоняет только в XE2, потому как использует нативные строки, а в Delphi 2007 завязано на WideString и Alcinoe вырывается вперёд.

И в нашем случае, что DOM, что SAX, разница в быстродействии небольшая (в пользу SAX). Проверял оба варианта. Видно дерево плоское, без вложений, поэтому и работает быстро.

(0014619)
vdemidov   
07-09-2014 19:28   
(edited on: 07-09-2014 19:48)
На моей машине скомпиленный тобой в XE2 екзешник OXml in SAX mode рвет MidasLib почти в 2 раза, а в скомпиленном в Delphi2007 только чуть-чуть отстает от MidasLib. Так что это все еще открытый вопрос. Но в общем и целом я с тобой согласен. Больше форматов хороших и разных. Как насчет сделать почти копию формата Sml, но запихнуть в базу SQLite? Только в блобы нормальные даблы сохранять, а не 10-байтовые :)

(0014620)
zed   
07-09-2014 20:09   
> OXml in SAX mode рвет MidasLib почти в 2 раза
А ты в Midas смотришь тот который LoadFromStream? Использование метода SetXML можно считать неактуальным. И на моих данных xml парсер всегда проигрывает датасету. Не 2 раза, но в 1,5 - точно. К тому же учти, что после парсинга данные куда-то ещё нужно и загонять, чтобы не тупой массив был, а с возможностью быстрого поиска по id и по name. А на это тоже нужно время. Имхо, оптимальным вариантом считаю датасет в бинарном виде. Можно даже сделать незаметную для пользователя миграцию в следующем релизе.

> Как насчет сделать почти копию формата Sml, но запихнуть в базу SQLite?
Почти копию сделать легко, но будет ли от неё прок? В SACS вон какая навороченная модель сделана. И писал её не школьник, а человек со знанием дела, так что я верю, что лишнего там ничего нету. И упрощённая модель может оказаться таким же нерасширяемым огрызком как и sml.
(0014621)
zed   
07-09-2014 20:18   
А SQLite мне очень нравится в качестве кандидата на хранилище меток, тем более когда я немного вник в вопрос и узнал о таких фишках как FTS и R-Tree из коробки, которые в SACS, кстати, не используются, насколько я могу судить. Так что над моделью нужно очень серъёзно думать.
(0014622)
vdemidov   
07-09-2014 20:45   
> А ты в Midas смотришь тот который LoadFromStream?
Конечно.
> К тому же учти, что после парсинга данные куда-то ещё нужно и загонять, чтобы не тупой массив был, а с возможностью быстрого поиска по id и по name.
В текущей реализации, это совершенно не обязательно. Оно все в виде объектов хранится. Да и при реализации ленивого парсинга геометрий, можно просто блобы подгружать. Так что это пока не аргумент.

>И упрощённая модель может оказаться таким же нерасширяемым огрызком как и sml.
И не стоит пытаться объять необъятное. В первую очередь нужно сделать возможность выбирать движок хранения меток (экспорт-импорт через sml наконец-то есть), а уж сколько разных движков потом наделать это уже другой вопрос. И на базе SQLite можно будет кучу разных сделать. И без всякой расширяемости. Так что ИМХО не стоит переусложнять реализацию.
(0015282)
vasketsov   
19-02-2015 07:57   
>И на базе SQLite можно будет кучу разных сделать
Это возможно. Только предупреждаю, что если переносить то, что хранится сейчас в SML, в SQLite, хранилище будет "нерасширяемым" в некоторых потенциально важных аспектах. То есть, это несколько иная логика, чем у меня (расширяемость хранилища). Фактически, все новые плюшки вам придётся вкорячивать как новые типы хранилищ меток над SQlite, отчего их количество будет множиться, а внутри они будут сильно похожи друг на друга, зато с кучей CASEов и IFов, или того хуже, override-ов.

Если уж кровь из носа хочется "как сейчас, то тогда надо сделать "как сейчас" + вторая модель "полная", то есть, всего два, и второе "расширяемое", а вовсе не кучу. И поскольку у вас тут других спецов по проектированию БД я не наблюдаю, для второго типа хранилища меток лучше взять мою структуру как есть, а не заниматься самодеятельностью. И обновить при случае получится, и если что, на меня кивнуть можно.

>фишках как FTS и R-Tree из коробки, которые в SACS, кстати, не используются, насколько я могу судить
Не используются. Их возможно использовать, это вопрос правильного формирования DDL. А поскольку все DDL доступны для исправления снаружи, то проблемы в принципе нет. Разве что я не придумал, где конкретно это надо. SQLite же мной расматривается как обкатка переползания на взрослые СУБД, а там, в частности, нет проблем с тем, чтобы оптимально пройти по паре индексов between при наличии адекватной статистики (проблемы начинаются после 3-4 between поверх одного индекса). Хотя возможно как раз для SQLite оно и поможет. FTS можно натравить на поиск по "хранимым" тайлам в текстовом формате, типа wiki, но опять же, мне не надо, но в принципе возможно.

>я верю, что лишнего там ничего нету
Ну, в принципе, в структуре хранилища лишнее есть, просто всё зависит от того, что считать за минимально необходимый "набор", например:
а) административные ограничения по юзерам;
б) настройка отображения для категорий и меток по юзерам;
в) ссылки;
г) протоколирование изменений;
д) произвольные атрибуты меток и категорий;
е) плагины отображения для категорий меток;
ё) ...
Если ничего не надо, а охота просто переползти, то всё конечно сильно упрощается. Но получится именно нерасширяемый обрубок.
(0015284)
vdemidov   
19-02-2015 10:11   
В данном инциденте обсуждение SQLite оффтоп. Сам я метки переделывать в ближайшем будущем не планирую, но пул-реквесты с удовольствием изучу, если будут.