Вопросы по исходному коду

[zed]

который хранит весь набор меток для отображения на экране и, в случае необходимости, запрашивает

А он этот набор иногда очищает?

[vdemidov]

который хранит весь набор меток для отображения на экране и, в случае необходимости, запрашивает

А он этот набор иногда очищает?

Очищает, если отключается отображение меток. Во всех остальных случаях он просто заменяется более актуальным. Но делает это всегда воркер, который у тебя упал после ошибки обращения к базе меток, так что этот набор при таких условиях очищаться не будет.

[zed]

Ну, то что оно упало, меня мало волнует. Меня волнует, что вся база меток залетает в память. И насколько я вижу, отключение видимости меток, на занимаемой памяти никак не сказывается.
Я надеялся, что отключив кэш в памяти для меток, снизится потребление памяти, а оно как-то совсем не заметно. Только на каждый чих из базы тягать метки приходится.

[vdemidov]

Ну, то что оно упало, меня мало волнует. Меня волнует, что вся база меток залетает в память. И насколько я вижу, отключение видимости меток, на занимаемой памяти никак не сказывается.
Я надеялся, что отключив кэш в памяти для меток, снизится потребление памяти, а оно как-то совсем не заметно. Только на каждый чих из базы тягать метки приходится.

Она залезает в память, только если вся отображается на экране и очищается при отключении меток. Так что если меток на экране немного, то и в памяти их будет немного. Но если ты хочешь отобразить все метки на нулевом зуме, то тебе в любом случае придется их все загрузить в память.

[zed]

Ок, ты меня успокоил.

Появился ещё вопрос, что надо сделать, чтобы прикрутить фильтр по размеру меток, чтобы не вытягивать из базы то, что отобразить в конечном итоге не получится. Об этом был тикет, и вроде там какое-то простое решение возможно? Я думаю, пришла пора его опробовать. Подскажи, чего и как?

[vdemidov]

Ну вроде как сошлись на том, что нужно добавить в запрос прямоугольника меток параметр с минимальными шириной и высотой геометрий в LonLat и при отборе из базы отбрасывать те метки у которых MBR меньше этих значений. А вот как эти минимальные значения выбирать в TVectorItemSubsetChangeableForMarksLayer это уже нужно подумать. Например размер запрашиваемого прямоугольника делить на количество пикселей в спроецированной версии этого прямоугольника.

[zed]

Определить средний размер пикселя в LonLat координатах для текущего прямоугольника и передать этот размер?

[vdemidov]

Определить средний размер пикселя в LonLat координатах для текущего прямоугольника и передать этот размер?

Ну да. Возможно умножить его на какую-то константу. Или параметр завести в каком-то конфиге, если есть подходящий.

[vasketsov]

Во-первых, все запросы в базу (даже на чтение) получают отлуп от SQLite с сообщением, что база заблокирована

Может быть ORM открывает базу как-то эксклюзивно?
Многоюзерное чтение должно быть в остальных случаях без проблем.
Даже если читать в рамках транзакции.

Частично работает опция Информация о метке: в базу прилетает запрос, обламывается, но окошко с информацией появляется и в сводной информации всё заполнено: площадь, количество частей и проч. Не отображается только описание метки.

Вообще довольно странно, что ровно один запрос из пяти не закэширован.
Я бы предположил, что особенность в кэшировании BLOBов на уровне ORM.

где оно кэшируется и как долго тот кэш живёт?

Может внутри ORM-а?

[zed]

Может быть ORM открывает базу как-то эксклюзивно?
Многоюзерное чтение должно быть в остальных случаях без проблем.

Ну, вторая копия читала всё на ура. Даже смогла метку записать в базу, но эта запись была фатальной для обеих копий программы.

Вообще довольно странно, что ровно один запрос из пяти не закэширован.

Не, ORM тут ни при чём. Я поставил брекпоинты на чтение данных из базы - на них просто не прилетали запросы, так что до ORM дело не доходило. А когда доходило (при открытии управления метками, к примеру), то падало с SQLITE_BUSY(5). Как верно заметил vdemidov, из-за самого первого эксепшена в базе, умер поток, который слушал базу и ходил за метками для отрисовки, вот оно и застыло.

Про кэширование в ORM вычитал: там есть Statement cache и небольшой Global JSON result cache (всего 16 Мб по дефолту), так что оно особой погоды не делает, а помогает бороться с однотипными запросами, которые идут один за одним.

А как там сделать многопользовательское чтение/запись в метки, нужно думать много и усердно. У тебя как это сделано?