0002519: Добавить In-Mem базу меток для хранения временных меток

Notes
(0014771) vdemidov (manager) 29-10-2014 10:21	В общем, пример для подражания Google Earth

(0016687) zed (manager) 02-11-2015 15:25	Завести ещё одну глобальную переменную типа FMarkSystemTemp: IMarkSystem и всюду где есть обращение к нормальной базе меток, добавить и эту? По сути, там не так уж и много мест, где оно используется. Или можно сделать некий IMarkSystemProvider у которого можно будет попросить In-Memory БД и обычную БД (а то и несколько обычных, если сильно захотеть). Само хранилище в памяти легко добавляется в ORM метках, там достаточно SQLite3 открывать с параметром :memory:, вместо пути к файлу. Соответственно, в IMarkSystem нужно будет добавить признак, в каком режиме его открывать.

(0016688) vdemidov (manager) 02-11-2015 16:15	ИМХО проще из SML базы выковырять откусив всю работу с xml

(0016689) zed (manager) 02-11-2015 17:14	Это вообще вопрос вторичный, главное сделать обвязку уровнем выше и посмотреть какие грабли вылезут.

(0016691) vdemidov (manager) 03-11-2015 08:23	> Завести ещё одну глобальную переменную типа FMarkSystemTemp: IMarkSystem и всюду где есть обращение к нормальной базе меток, добавить и эту? А может спрятать это все внутри IMarkSystem? Пусть для остальных частей программы это выглядит как одна база меток. Нужно только при тихом импорте (через командную строку или сообщение) правильно указывать категорию. А уже подсистема меток сама определит в какую из физических баз запихать конкретные метки. Да и при отображении в менеджере меток, лучше что бы сама система объединяла дерево категорий разных баз.

(0016697) zed (manager) 03-11-2015 10:23	По-моему, так не получится или получится слишком сложно. Во-первых, нам надо чётко знать, пустая временная БД при закрытии программы или нет, чтобы предупредить пользователя. Во-вторых, при перемещении метки из временной базы в нормальную, нужно делать insert вместо обновления, т.е. нужно отслеживать, что вот эта категория на самом деле находится в другой БД, а не в текущей. И ещё, мне кажется, чтобы однозначно идентифицировать принадлежность меток, нам придётся расширить интерфейс IMarkID и добавить туда uid метки и БД + тоже самое сделать и для IMarkCategory.

(0016699) vdemidov (manager) 03-11-2015 10:48	> Во-первых, нам надо чётко знать, пустая временная БД при закрытии программы или нет, чтобы предупредить пользователя. Эту проверку делать все равно добавлять. Сейчас нет способа узнать пустая база или нет. > Во-вторых, при перемещении метки из временной базы в нормальную, нужно делать insert вместо обновления, т.е. нужно отслеживать, что вот эта категория на самом деле находится в другой БД, а не в текущей. Это придется делать в любом случае, если ты не хочешь выделить временную базу вообще в отдельный ГУИ без возможности драг энд дропа между базами. А так вся логика поддержки временной базы будет сосредоточена в одном классе. > И ещё, мне кажется, чтобы однозначно идентифицировать принадлежность меток, нам придётся расширить интерфейс IMarkID и добавить туда uid метки и БД + тоже самое сделать и для IMarkCategory. Возможно. И пусть лучше вся эта кухня прячется внутри одного класса, а не будет размазана по всей программе

(0018134) stepanxxx (reporter) 25-10-2017 21:08	Откликнитесь! Действительно данная функция нужна!

(0018135) zed (manager) 26-10-2017 18:37	Вы готовы заплатить за это сколько-нибудь денег?

(0018136) stepanxxx (reporter) 26-10-2017 20:17	На ya.деньги смогу донатить?

(0018137) zed (manager) 26-10-2017 20:20	У меня только вебмани. Сколько предлагаете?

(0018138) stepanxxx (reporter) 26-10-2017 20:25	Говорилось про сколько-нибудь! (выше). А теперь от количества зависит выполнение хотелки? Отсюда вопрос - сколько? Ну и номер WMR

(0018139) zed (manager) 27-10-2017 06:49	Я просто уточнял, готовы ли вы вообще к тому, что за это придётся платить. Готов взяться за эту хотелку за 3000 рублей. Предоплата. За номером кошелька обращайтесь ко мне на почту: [email protected].

Users who viewed this issue
User List	Anonymous (3588x), SlavutichRED (2x), stepanxxx (31x), zed (20x), OfK (1x), vdemidov (16x), karat440 (1x), bk99 (2x), ingener (2x), rass (1x), elCamino (2x), Crursh-91 (2x), Papazol (1x)
Total Views	3669
Last View	21-11-2024 16:01

Issue History
Date Modified	Username	Field	Change
29-10-2014 10:17	vdemidov	New Issue
29-10-2014 10:17	vdemidov	Issue generated from: 0000033
29-10-2014 10:17	vdemidov	Relationship added	child of 0000033
29-10-2014 10:18	vdemidov	Reproducibility	have not tried => N/A
29-10-2014 10:18	vdemidov	Status	new => confirmed
29-10-2014 10:18	vdemidov	Platform	Любая =>
29-10-2014 10:21	vdemidov	Note Added: 0014771
21-01-2015 10:39	vdemidov	Target Version	150915 => 151010
04-10-2015 15:30	vdemidov	Target Version	151010 => 151111
02-11-2015 15:25	zed	Note Added: 0016687
02-11-2015 16:15	vdemidov	Note Added: 0016688
02-11-2015 17:14	zed	Note Added: 0016689
03-11-2015 08:23	vdemidov	Note Added: 0016691
03-11-2015 10:23	zed	Note Added: 0016697
03-11-2015 10:48	vdemidov	Note Added: 0016699
06-11-2015 08:19	vdemidov	Target Version	151111 => 191221
08-10-2017 10:37	zed	Relationship added	child of 0003283
25-10-2017 21:08	stepanxxx	Note Added: 0018134
26-10-2017 18:37	zed	Note Added: 0018135
26-10-2017 20:17	stepanxxx	Note Added: 0018136
26-10-2017 20:20	zed	Note Added: 0018137
26-10-2017 20:25	stepanxxx	Note Added: 0018138
27-10-2017 06:49	zed	Note Added: 0018139
27-03-2019 08:17	vdemidov	Relationship replaced	has duplicate 0003283
23-07-2019 16:56	vdemidov	Target Version	191221 => 211230
30-12-2021 08:58	zed	Target Version	211230 => 26xxxx

SASGIS