View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001217 | SAS.Планета | Рефакторинг / Refactoring | public | 14-03-2012 18:19 | 19-02-2015 10:11 |
| Reporter | vasketsov | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | confirmed | Resolution | open | ||
| Platform | Windows | OS | Vista | OS Version | Ultimate |
| Product Version | 110418 | ||||
| Target Version | 44xxxx | ||||
| Summary | 0001217: Избавиться от MidasLib | ||||
| Description | Избавиться от использования датасетов при работе с sml файлами. | ||||
| Tags | библиотеки | ||||
| Attached Files | |||||
|
|
Помнится раньше были проблемы при запуске чистой версии без созданных sml файлов. |
|
|
Что без sml при запуске, что с ними - отклонений в работе меток не нашёл. Голосую, убить! (C) мультфильм "Остров сокровищ". |
|
|
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 на что-то более современное |
|
|
А еще перед революционными изменениями нужно сделать нормальный экспорт-импорт с минимальными потерями информации. |
|
|
<тут был оффтопик> |
|
|
К этому топику 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 пописать, и т.п. После моих доработок стороннего отваливается всегда ровно ноль, у меня политика такая, и её тебе же желаю оценить и придерживатьс её. >Когда можно будет переключаться между разными движками на лету Я эту возможность постулировал несколько сообщений назад, одень глаза и утри ЧСВ. |
|
|
Провёл некоторые тесты (в аттаче) и пришёл к выводу, что в 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-парсер использовать. |
|
|
Именно SAX использовал. Качни архив, посмотри в сорцы. OXml взял спецом, потому как на родном сайте уж очень её хвалили за скорость. По их тестам обгоняет Alcinoe, по моим - обгоняет только в XE2, потому как использует нативные строки, а в Delphi 2007 завязано на WideString и Alcinoe вырывается вперёд. И в нашем случае, что DOM, что SAX, разница в быстродействии небольшая (в пользу SAX). Проверял оба варианта. Видно дерево плоское, без вложений, поэтому и работает быстро. |
|
|
На моей машине скомпиленный тобой в XE2 екзешник OXml in SAX mode рвет MidasLib почти в 2 раза, а в скомпиленном в Delphi2007 только чуть-чуть отстает от MidasLib. Так что это все еще открытый вопрос. Но в общем и целом я с тобой согласен. Больше форматов хороших и разных. Как насчет сделать почти копию формата Sml, но запихнуть в базу SQLite? Только в блобы нормальные даблы сохранять, а не 10-байтовые :) |
|
|
> OXml in SAX mode рвет MidasLib почти в 2 раза А ты в Midas смотришь тот который LoadFromStream? Использование метода SetXML можно считать неактуальным. И на моих данных xml парсер всегда проигрывает датасету. Не 2 раза, но в 1,5 - точно. К тому же учти, что после парсинга данные куда-то ещё нужно и загонять, чтобы не тупой массив был, а с возможностью быстрого поиска по id и по name. А на это тоже нужно время. Имхо, оптимальным вариантом считаю датасет в бинарном виде. Можно даже сделать незаметную для пользователя миграцию в следующем релизе. > Как насчет сделать почти копию формата Sml, но запихнуть в базу SQLite? Почти копию сделать легко, но будет ли от неё прок? В SACS вон какая навороченная модель сделана. И писал её не школьник, а человек со знанием дела, так что я верю, что лишнего там ничего нету. И упрощённая модель может оказаться таким же нерасширяемым огрызком как и sml. |
|
|
А 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 оффтоп. Сам я метки переделывать в ближайшем будущем не планирую, но пул-реквесты с удовольствием изучу, если будут. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 14-03-2012 18:19 | vasketsov | New Issue | |
| 14-03-2012 19:31 | vdemidov | Note Added: 0006103 | |
| 14-03-2012 19:50 | vasketsov | Note Added: 0006104 | |
| 14-03-2012 20:15 | zed | Note Added: 0006105 | |
| 14-03-2012 20:25 | vdemidov | Note Added: 0006106 | |
| 14-03-2012 20:30 | vasketsov | Note Added: 0006107 | |
| 14-03-2012 20:35 | vdemidov | Note Added: 0006108 | |
| 14-03-2012 20:41 | vdemidov | Note Added: 0006109 | |
| 22-03-2012 09:59 | gpsMax | Tag Attached: библиотеки | |
| 23-03-2012 19:26 | vdemidov | Status | new => confirmed |
| 23-03-2012 19:26 | vdemidov | Target Version | => 42xxxx |
| 23-03-2012 19:26 | vdemidov | Summary | MidasLib => Избавиться от MidasLib |
| 23-03-2012 19:26 | vdemidov | Description Updated | |
| 09-08-2012 06:53 | vdemidov | Product Version | .Nightly => 110418 |
| 30-12-2012 20:39 | vasketsov | Relationship added | related to 0001481 |
| 30-12-2012 20:47 | vasketsov | Note Added: 0010270 | |
| 30-12-2012 20:47 | vasketsov | Tag Attached: SQLite | |
| 30-12-2012 21:34 | vdemidov | Note Added: 0010273 | |
| 30-12-2012 21:35 | vdemidov | Relationship replaced | parent of 0001481 |
| 30-12-2012 21:35 | vdemidov | Note Added: 0010274 | |
| 30-12-2012 22:15 | vasketsov | Note Added: 0010275 | |
| 30-12-2012 22:15 | vasketsov | Tag Detached: SQLite | |
| 30-12-2012 22:17 | vasketsov | Note Edited: 0010270 | |
| 30-12-2012 22:35 | vdemidov | Note Added: 0010276 | |
| 30-12-2012 22:35 | vdemidov | Relationship added | parent of 0000304 |
| 30-12-2012 23:09 | vasketsov | Note Added: 0010277 | |
| 31-12-2012 16:44 | vdemidov | Note Added: 0010287 | |
| 31-12-2012 18:39 | vasketsov | Note Added: 0010288 | |
| 07-09-2014 17:43 | zed | File Added: sml_load.zip | |
| 07-09-2014 17:59 | zed | Note Added: 0014611 | |
| 07-09-2014 18:41 | vdemidov | Note Added: 0014615 | |
| 07-09-2014 18:47 | zed | Note Added: 0014616 | |
| 07-09-2014 18:48 | zed | Note Edited: 0014616 | |
| 07-09-2014 19:28 | vdemidov | Note Added: 0014619 | |
| 07-09-2014 19:48 | vdemidov | Note Edited: 0014619 | |
| 07-09-2014 20:09 | zed | Note Added: 0014620 | |
| 07-09-2014 20:18 | zed | Note Added: 0014621 | |
| 07-09-2014 20:45 | vdemidov | Note Added: 0014622 | |
| 19-02-2015 05:28 | zed | Relationship added | child of 0002107 |
| 19-02-2015 07:57 | vasketsov | Note Added: 0015282 | |
| 19-02-2015 10:11 | vdemidov | Note Added: 0015284 | |
| 19-02-2015 10:11 | vdemidov | Target Version | 42xxxx => 44xxxx |
| 08-08-2025 13:25 | zed | Category | Рефакторинг => Рефакторинг / Refactoring |