|
Notes |
|
|
|
|
Помнится раньше были проблемы при запуске чистой версии без созданных sml файлов. |
|
|
|
|
Что без 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) |
|
|
|
|
|
А, точно. Совсем забыл. А вообще нужен ридер и врайтер для sml файлов, что бы вообще отказаться от датасетов и midas |
|
|
|
|
|
Может MidasLib убить вместе с sml? Ну конечно не прямо сейчас, а чуть погодя? |
|
|
|
|
|
В том то и дело, что хочется это сделать плавно. То есть, сначала нужно сделать возможность выбора движка для хранения меток, а уж потом замена дефолтного с sml на что-то более современное |
|
|
|
|
|
А еще перед революционными изменениями нужно сделать нормальный экспорт-импорт с минимальными потерями информации. |
|
|
|
(0010270)
|
|
vasketsov
|
30-12-2012 20:47
(edited on: 30-12-2012 22:17) |
|
|
|
|
|
|
К этому топику SQLite никакого отношения не имеет. |
|
|
|
|
|
И кстати, пока этот рефакторинг не будет выполнен, ни о каких переделках базы меток речь идти не будет. |
|
|
|
|
>К этому топику SQLite никакого отношения не имеет
Хм. Пожалуй да, это я погорячился, ща удалю ссылочку.
>пока этот рефакторинг не будет выполнен, ни о каких переделках базы меток речь идти не будет
Ты уже праздновать начал? ))))
Этот пункт никакого отношения не имеет к меткам не в SML.
Этот пункт надо просто закрыть и вообще не делать. После отказа от SML (а для этого надо сделать метки не в SML, и процедура сохранения собственно и будет процедурой экспорта aka конвертирования SML-XXX) через пару релизов вычистить метки в SML - и всё спокойно умрёт своей смертью. |
|
|
|
|
|
Вот сделай импорт-экспорт в sml без потерь данных, а потом будем обсуждать что делать дальше. |
|
|
|
|
>сделай импорт-экспорт в sml без потерь данных
Зачем?
Достаточно забацать модель данных + сделать настройку откуда читать метки + сделать настройку куда сохранять метки + добавить сохранение прочтённых меток не в SML (а в БД) и чтение их оттуда.
Сделать копирование меток из БД в SML без потери нереально по определению, потеря информации будет обязательно, так как полей и данных будет больше, чем сейчас.
Если я правильно понял - достаточно переписать:
TMarksSystem(IMarksSystem) в u_MarksSystem
TMarksDb(IMarksDb) в u_MarksDb
там правда болтается IMarksDbSmlInternal, но принципиально он ничего не портит, я не вижу связи снаружи этих интерфейсов с SML. Может конечно плохо искал ((. Все интерфейсы из i_MarksDbSmlInternal привязки к SML не имеют. Пока-что не вижу проблем в имплементации выше уровня SML.
Разумеется, если бы был интерфейс именно для работы напрямую с метками в хранилище (прочитать/сохранить/удалить одну/кучку/по Zoom+Rect, и т.п.), было бы проще, оно бы прямо на SQL ложилось бы, но в общем-то и имеющегося вроде бы достаточно. |
|
|
|
|
>Сделать копирование меток из БД в SML без потери нереально по определению, потеря информации будет обязательно, так как полей и данных будет больше, чем сейчас.
Ну-ну. При том что сейчас база хранится именно в sml это реально по определению. В общем, любые изменения нарушающие совместимость с метками старых версий вводи только в отдельной ветке или я их буду откатывать. Когда можно будет переключаться между разными движками на лету, тогда и вольем в основную ветку. |
|
|
|
|
>это реально по определению
Хм. Или "без потери данных" у тебя какой-то свой смысл имеет, или одно из двух. Достаточно мне добавить ОДНО поле 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, то всегда можно получить текстовый бекап меток. |
|
|
|
|
|
А ты проверял другие 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, кстати, не используются, насколько я могу судить. Так что над моделью нужно очень серъёзно думать. |
|
|
|
|
> А ты в Midas смотришь тот который LoadFromStream?
Конечно.
> К тому же учти, что после парсинга данные куда-то ещё нужно и загонять, чтобы не тупой массив был, а с возможностью быстрого поиска по id и по name.
В текущей реализации, это совершенно не обязательно. Оно все в виде объектов хранится. Да и при реализации ленивого парсинга геометрий, можно просто блобы подгружать. Так что это пока не аргумент.
>И упрощённая модель может оказаться таким же нерасширяемым огрызком как и sml.
И не стоит пытаться объять необъятное. В первую очередь нужно сделать возможность выбирать движок хранения меток (экспорт-импорт через sml наконец-то есть), а уж сколько разных движков потом наделать это уже другой вопрос. И на базе SQLite можно будет кучу разных сделать. И без всякой расширяемости. Так что ИМХО не стоит переусложнять реализацию. |
|
|
|
|
>И на базе SQLite можно будет кучу разных сделать
Это возможно. Только предупреждаю, что если переносить то, что хранится сейчас в SML, в SQLite, хранилище будет "нерасширяемым" в некоторых потенциально важных аспектах. То есть, это несколько иная логика, чем у меня (расширяемость хранилища). Фактически, все новые плюшки вам придётся вкорячивать как новые типы хранилищ меток над SQlite, отчего их количество будет множиться, а внутри они будут сильно похожи друг на друга, зато с кучей CASEов и IFов, или того хуже, override-ов.
Если уж кровь из носа хочется "как сейчас, то тогда надо сделать "как сейчас" + вторая модель "полная", то есть, всего два, и второе "расширяемое", а вовсе не кучу. И поскольку у вас тут других спецов по проектированию БД я не наблюдаю, для второго типа хранилища меток лучше взять мою структуру как есть, а не заниматься самодеятельностью. И обновить при случае получится, и если что, на меня кивнуть можно.
>фишках как FTS и R-Tree из коробки, которые в SACS, кстати, не используются, насколько я могу судить
Не используются. Их возможно использовать, это вопрос правильного формирования DDL. А поскольку все DDL доступны для исправления снаружи, то проблемы в принципе нет. Разве что я не придумал, где конкретно это надо. SQLite же мной расматривается как обкатка переползания на взрослые СУБД, а там, в частности, нет проблем с тем, чтобы оптимально пройти по паре индексов between при наличии адекватной статистики (проблемы начинаются после 3-4 between поверх одного индекса). Хотя возможно как раз для SQLite оно и поможет. FTS можно натравить на поиск по "хранимым" тайлам в текстовом формате, типа wiki, но опять же, мне не надо, но в принципе возможно.
>я верю, что лишнего там ничего нету
Ну, в принципе, в структуре хранилища лишнее есть, просто всё зависит от того, что считать за минимально необходимый "набор", например:
а) административные ограничения по юзерам;
б) настройка отображения для категорий и меток по юзерам;
в) ссылки;
г) протоколирование изменений;
д) произвольные атрибуты меток и категорий;
е) плагины отображения для категорий меток;
ё) ...
Если ничего не надо, а охота просто переползти, то всё конечно сильно упрощается. Но получится именно нерасширяемый обрубок. |
|
|
|
|
|
В данном инциденте обсуждение SQLite оффтоп. Сам я метки переделывать в ближайшем будущем не планирую, но пул-реквесты с удовольствием изучу, если будут. |
|
sml_load.zip (3,127,534) 07-09-2014 17:43