0001217: Избавиться от MidasLib

Notes
(0006103) vdemidov (manager) 14-03-2012 19:31	Помнится раньше были проблемы при запуске чистой версии без созданных sml файлов.

(0006104) vasketsov (manager) 14-03-2012 19:50	Что без sml при запуске, что с ними - отклонений в работе меток не нашёл. Голосую, убить! (C) мультфильм "Остров сокровищ".

(0006105) zed (manager) 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 (manager) 14-03-2012 20:25	А, точно. Совсем забыл. А вообще нужен ридер и врайтер для sml файлов, что бы вообще отказаться от датасетов и midas

(0006107) vasketsov (manager) 14-03-2012 20:30	Может MidasLib убить вместе с sml? Ну конечно не прямо сейчас, а чуть погодя?

(0006108) vdemidov (manager) 14-03-2012 20:35	В том то и дело, что хочется это сделать плавно. То есть, сначала нужно сделать возможность выбора движка для хранения меток, а уж потом замена дефолтного с sml на что-то более современное

(0006109) vdemidov (manager) 14-03-2012 20:41	А еще перед революционными изменениями нужно сделать нормальный экспорт-импорт с минимальными потерями информации.

(0010270) vasketsov (manager) 30-12-2012 20:47 edited on: 30-12-2012 22:17	<тут был оффтопик>

(0010273) vdemidov (manager) 30-12-2012 21:34	К этому топику SQLite никакого отношения не имеет.

(0010274) vdemidov (manager) 30-12-2012 21:35	И кстати, пока этот рефакторинг не будет выполнен, ни о каких переделках базы меток речь идти не будет.

(0010275) vasketsov (manager) 30-12-2012 22:15	>К этому топику SQLite никакого отношения не имеет Хм. Пожалуй да, это я погорячился, ща удалю ссылочку. >пока этот рефакторинг не будет выполнен, ни о каких переделках базы меток речь идти не будет Ты уже праздновать начал? )))) Этот пункт никакого отношения не имеет к меткам не в SML. Этот пункт надо просто закрыть и вообще не делать. После отказа от SML (а для этого надо сделать метки не в SML, и процедура сохранения собственно и будет процедурой экспорта aka конвертирования SML-XXX) через пару релизов вычистить метки в SML - и всё спокойно умрёт своей смертью.

(0010276) vdemidov (manager) 30-12-2012 22:35	Вот сделай импорт-экспорт в sml без потерь данных, а потом будем обсуждать что делать дальше.

(0010277) vasketsov (manager) 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 (manager) 31-12-2012 16:44	>Сделать копирование меток из БД в SML без потери нереально по определению, потеря информации будет обязательно, так как полей и данных будет больше, чем сейчас. Ну-ну. При том что сейчас база хранится именно в sml это реально по определению. В общем, любые изменения нарушающие совместимость с метками старых версий вводи только в отдельной ветке или я их буду откатывать. Когда можно будет переключаться между разными движками на лету, тогда и вольем в основную ветку.

(0010288) vasketsov (manager) 31-12-2012 18:39	>это реально по определению Хм. Или "без потери данных" у тебя какой-то свой смысл имеет, или одно из двух. Достаточно мне добавить ОДНО поле speed для точек трека - и уже не будет конвертации SQL-SML-SQL без потери точности ))). Вкуриваешь? >любые изменения нарушающие совместимость Давай ты для начала начнёшь с себя? Пока что из всех кто приложил лапу, именно от тебя больше всего ситуаций, когда что-то стороннее отваливается, а восстанавливать ты даже не собираешься. Так что в очередной раз желаю повзрослеть и в будущем году уважительнее относиться к чужому труду, как минимум перед доработкой хотя бы простым поиском проверить, что будет если например contenttype пописать, и т.п. После моих доработок стороннего отваливается всегда ровно ноль, у меня политика такая, и её тебе же желаю оценить и придерживатьс её. >Когда можно будет переключаться между разными движками на лету Я эту возможность постулировал несколько сообщений назад, одень глаза и утри ЧСВ.

(0014611) zed (manager) 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 (manager) 07-09-2014 18:41	А ты проверял другие DOM или SAX парсеры? Тут нужно именно SAX-парсер использовать.

(0014616) zed (manager) 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 (manager) 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 (manager) 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 (manager) 07-09-2014 20:18	А SQLite мне очень нравится в качестве кандидата на хранилище меток, тем более когда я немного вник в вопрос и узнал о таких фишках как FTS и R-Tree из коробки, которые в SACS, кстати, не используются, насколько я могу судить. Так что над моделью нужно очень серъёзно думать.

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

(0015282) vasketsov (manager) 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 (manager) 19-02-2015 10:11	В данном инциденте обсуждение SQLite оффтоп. Сам я метки переделывать в ближайшем будущем не планирую, но пул-реквесты с удовольствием изучу, если будут.

Users who viewed this issue
User List	Anonymous (3755x), vdemidov (3x), zed (2x)
Total Views	3760
Last View	23-04-2024 11:09

Issue History
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	=> 26xxxx
23-03-2012 19:26	vdemidov	Summary	MidasLib => Избавиться от MidasLib
23-03-2012 19:26	vdemidov	Description Updated	View Revisions
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	View Revisions
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	View Revisions
07-09-2014 19:28	vdemidov	Note Added: 0014619
07-09-2014 19:48	vdemidov	Note Edited: 0014619	View Revisions
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	26xxxx => 29xxxx

SASGIS