0001753: Многопользовательский интерфейс при работе с метками.

Notes
(0010271) vasketsov (manager) 30-12-2012 20:53	>Большая просьба реализовать такую возможность. Есть уверенность, что SML в принципе тупиковый путь. Вряд ли кого-то заинтересуете этим. >вывести поле visible Ну а потом захочется не Visible, а какое-то другое свойство настраивать, например диапазон зумов видимости. Ещё делить метки? Негуманно. Разумеется необходимо соблюсти общий принцип - ДАННЫЕ отделены от их ОТОБРАЖЕНИЯ, соответственно ОТОБРАЖЕНИЕ у всех своё и настраиваемое. Но SML...

(0010272) Fed (reporter) 30-12-2012 21:22	>Есть уверенность, что SML в принципе тупиковый путь. Вряд ли кого-то заинтересуете этим. Полностью с этим согласен, если релизовать в СУБД, то это было бы просто СУПЕР. Предложение сделать первые шаги к этому, разделить таблицу на две части (одна у пользователя /можно оставить в файле/, а другая например на сервере /перенести в СУБД/). >Разумеется необходимо соблюсти общий принцип - ДАННЫЕ отделены от их ОТОБРАЖЕНИЯ, соответственно ОТОБРАЖЕНИЕ у всех своё и настраиваемое. Об этом собственно и речь! Просто visible стоит на первом месте(чаще всего используем), по этому на него обратил особое внимание.

(0010278) Fed (reporter) 31-12-2012 04:34 edited on: 31-12-2012 04:59	В http://sasgis.org/mantis/view.php?id=1113 описывается метод хранения данных (кеш) в СУБД, таким же образом в СУБД можно хранить и ДАННЫЕ МЕТОК. Как описывается в http://sasgis.org/mantis/view.php?id=1481#c8473 перевод меток в СУБД (особенно в части с данными) может ускорить работу программы.

(0010280) sheavy (reporter) 31-12-2012 05:31	Согласен с vasketsov и Fed. Вижу, что эта тема уже долго обсуждается. Сложность перехода на БД очевидна. Возможно, разделение по разным файлам было бы хорошим прототипом или переходной ступенью. При таком подходе будет проще с конвертором. Он даже может быть встроен в саму программу.

(0010281) vasketsov (manager) 31-12-2012 05:39	>разделение по разным файлам было бы хорошим прототипом или переходной ступенью Нет. Разделение бессмысленное. Тупик. >будет проще с конвертором Ровно наоборот. Любые усложнения сейчас - потом потребуется учитывать в конвертере. >Он даже может быть встроен в саму программу Он даже не нужен совершенно, если в самой программе будет тривиальная "галочка", в каком формате метки. Переключение её приведёт к тому, что метки сохранятся уже в новом формате. Даже старые останутся в виде бэкапа.

(0010282) Fed (reporter) 31-12-2012 05:56 edited on: 31-12-2012 05:58	Что Вы думаете о возможности перевода ДАННЫХ меток в СУБД, а их ОТОБРАЖЕНИЯ оставить на ПК пользователей (на данный момент в файле)? Насколько это реалистично? Было бы хорошо реализовать такую возможность.

(0010283) vasketsov (manager) 31-12-2012 06:11	>на данный момент в файле Не вижу смысла. Там всё куда проще, чем изначально показалось. Возможно даже сегодня сделаю, если успею, безо всякого деления по файлам.

(0010284) Fed (reporter) 31-12-2012 07:51	>Там всё куда проще, чем изначально показалось. >Возможно даже сегодня сделаю, если успею, безо всякого деления по файлам. ДАННЫЕ отделены от их ОТОБРАЖЕНИЯ? Настройки изображения для каждого пользователя должны оставаться свои, тогда как данные - общие. Значит в базу нужно добавить id-пользователя.

(0010285) sheavy (reporter) 31-12-2012 08:03	А как определить что это за пользователь? Если вводить систему аутентификации - это усложнение. вариант 1: по имени комптютера. По ip-нельзя, т.к. адрес может меняться особенно если в сети используется dhcp. вариант 2 (лучший чем 1): автоматически при первом запуске в ini-файл пользователя прописывается очередной id, который используется при последующих запусках. Только будут накапливаться уже неиспользуемые id и понадобится механизм их удаления

(0010286) vasketsov (manager) 31-12-2012 13:38	>ДАННЫЕ отделены от их ОТОБРАЖЕНИЯ? Ещё пока нет. Я лишь "перекрыл" использование SML и датасетов над ним, и заменил на SQLite (вернее ещё не полностью, для БД категорий меток ещё не повторено до конца). Работы было на пару часов )). Но сегодня уже даже запускать и тестить не буду )) а то натестчу )). >безо всякого деления по файлам Возможно я погорячился, так что и правда правильнее будет в отдельном файле (но всё равно в БД не в SML) в профиле хранить настройки отображения для меток. Во всяком случае при смерти профиля пользователя эти настройки сами умрут. В любом случае задача удаления настроек отображения при удалении метки возникает и требует решения. >как определить что это за пользователь? По SID-у. Это как раз самое простое. >вводить систему аутентификации Аутентификация ни при чём. Даже права ни при чём. >автоматически при первом запуске в ini-файл пользователя прописывается очередной id Буквально всё то же самое: автоматически при создании пользователя ему прописывается очередной SID.

(0010289) Fed (reporter) 01-01-2013 06:00 edited on: 01-01-2013 06:10	>>ДАННЫЕ отделены от их ОТОБРАЖЕНИЯ? >Ещё пока нет. Я лишь "перекрыл" использование SML и датасетов над ним, и заменил на SQLite. Всё же, хорошо отделить данные от их отображений. >В любом случае задача удаления настроек отображения при удалении метки возникает и требует решения. Я думаю, это не столь сложно так, как у меток есть id, и при удалении метки можно удалить в таблице (особенно если данные будут в СУБД), отвечающей за отображение, все данные с id-метки. /Таблица отображения должна содержать следующие столбцы: id-пользователя(например sid), id-метки, visible/ >>как определить что это за пользователь? >По SID-у. Это как раз самое простое. SID (Идентификатор безопасности) не всегда удобно использовать, не из-за того что в некоторых случаях он может одинаковым (например при клонирование ПК с настроенными программами без смены SID-а). Проблема с использованием SID-а возникает при использовании терминального сервера (конечно к SID-у можно добавить RID), в этом случае SID одинаковый. Кажется лучше (или как альтернативу) использовать login пользователя, при этом работает он с программой на терминальном сервере или на своём ПК или за другим ПК в этом Домене, все настройки визуализации сохраняются.

(0010291) Fed (reporter) 02-01-2013 06:04	Реализовал возможность каскадной визуализации категории меток: http://sasgis.org/mantis/view.php?id=917#c10290 Так, как эти темы связаны друг с другом, можешь добавить эти изменения в следующий релиз (сборку)? Смотри вложение: frm_MarksExplorer.pas

(0010316) vasketsov (manager) 04-01-2013 15:12	Раз уж тут обсуждается многопользовательность - прикреплю модель сюда. Вернее не модель, а её экспорт в pdf для неимеющих PDViwer-а. Сама модель в репозитории лежит (https://bitbucket.org/vasketsov/tilestorage_dbms в папке model). Модель подразумевает возможность реализации всего, что ранее обсуждалось (включая мониторинг изменений, полигоны с дырками, многокомпонентные полигоны и полилинии, запреты удаления чужих категорий, разные настройки видимости и отображения, экспорт-импорт без потерь,...). Если чего забыл или непонятно - обсудим. >отделить данные от их отображений В общем-то для SQLite получается слишком извращённая ситуация. Так что если не получится на SQLite многопользовательность (затраты на неё слишком велики) - придётся поднимать СУБД. Там точно получится, причём всё. Пока что для SQLite всё идёт к тому, что БД меток ничего не будет знать о разных пользователях и будет максимум что не сохраняться целиком за раз + будет доступна на запись из нескольких сасов одновременно. То есть из полной модели пропадут поля ссылающиеся на пользователей, таблица пользователей (ну и логи заодно тоже), а таблички с настройками по пользователям отдадут свои последние поля родительским и тоже пропадут. Как-то так. >это не столь сложно так, как у меток есть id В СУБД это тривально, см. модель. В SQLite если относить настройки пользователя в профиль - это нетривиально, там нельзя обеспечить ссылочную целостность между базами, а если сложить пользовательские настройки в БД - при смене пользователя и смерти старого профиля она будет безосновательно пухнуть. И если в СУБД можно ОДНОЗНАЧНО понять, существует ли конкретный пользователь (логин), то в SQLite такого притерия не существует. >к SID-у можно добавить RID Насколько я знаю, SID в виде S-1-5-21-542808039-2109243029-4146833331-1012 (как он в HKEY_USERS) уже содержит RID. Кроме того, SID имеет смысл только в том случае, если в БД нет своих пользователей. Для взрослой БД надо указывать логин-пароль (или заходить с доменным) - соответственно логин в БД и будет идентифицировать пользователя, без всяких SID-ов. Хотите разные настройки - заходите под разными логинами.

(0010321) vasketsov (manager) 04-01-2013 22:44	>возможность каскадной визуализации категории меток Нет. В реальности категории не ссылаются друг на дружку (это не папки), и каждая имеет свою видимость. Там дерево только виртуальное, чтобы ничего не загромождать и быстро сворачивать Поэтому я наоборот против такого поведения. >если не получится на SQLite многопользовательность Думаю что получится. Придумал завести одного фиктивного юзера и всё делать по умолчанию под ним. Оверхэд (относительно безюзерности) - декларация 4 таблиц, думаю что это будет 8k. Надо многих - измЕните одну опцию, и сами будете при необходимости при смерти юзеров в домене вычищать БД.

(0010328) Fed (reporter) 05-01-2013 11:11	>>возможность каскадной визуализации категории меток >Нет. В реальности категории не ссылаются друг на дружку (это не папки), и каждая имеет свою видимость. >Там дерево только виртуальное, чтобы ничего не загромождать и быстро сворачивать Поэтому я наоборот против такого поведения. Механизм каскадной визуализации прост, можно сделать выбор использовать его или нет.

Users who viewed this issue
User List	Anonymous (2898x), SlavutichRED (1x), Drusja_1984 (1x), hrucker (8x), gamuer (1x), Fed (57x), BormanPB (6x)
Total Views	2972
Last View	24-11-2024 02:33

Issue History
Date Modified	Username	Field	Change
30-12-2012 20:48	Fed	New Issue
30-12-2012 20:53	vasketsov	Note Added: 0010271
30-12-2012 21:22	Fed	Note Added: 0010272
31-12-2012 04:15	Fed	Tag Attached: sml
31-12-2012 04:15	Fed	Tag Attached: БД
31-12-2012 04:15	Fed	Tag Attached: группы
31-12-2012 04:15	Fed	Tag Attached: интерфейс
31-12-2012 04:15	Fed	Tag Attached: метки
31-12-2012 04:15	Fed	Tag Attached: структура базы
31-12-2012 04:15	Fed	Tag Attached: многопользоватеская
31-12-2012 04:15	Fed	Tag Attached: совместная работа
31-12-2012 04:34	Fed	Note Added: 0010278
31-12-2012 04:36	Fed	Note Edited: 0010278	View Revisions
31-12-2012 04:44	Fed	Note Edited: 0010278	View Revisions
31-12-2012 04:45	Fed	Note Edited: 0010278	View Revisions
31-12-2012 04:45	Fed	Note Edited: 0010278	View Revisions
31-12-2012 04:46	Fed	Note Edited: 0010278	View Revisions
31-12-2012 04:59	Fed	Note Edited: 0010278	View Revisions
31-12-2012 05:31	sheavy	Note Added: 0010280
31-12-2012 05:39	vasketsov	Note Added: 0010281
31-12-2012 05:56	Fed	Note Added: 0010282
31-12-2012 05:58	Fed	Note Edited: 0010282	View Revisions
31-12-2012 06:11	vasketsov	Note Added: 0010283
31-12-2012 07:51	Fed	Note Added: 0010284
31-12-2012 08:03	sheavy	Note Added: 0010285
31-12-2012 13:38	vasketsov	Note Added: 0010286
01-01-2013 06:00	Fed	Note Added: 0010289
01-01-2013 06:01	Fed	Note Edited: 0010289	View Revisions
01-01-2013 06:02	Fed	Note Edited: 0010289	View Revisions
01-01-2013 06:05	Fed	Note Edited: 0010289	View Revisions
01-01-2013 06:08	Fed	Note Edited: 0010289	View Revisions
01-01-2013 06:10	Fed	Note Edited: 0010289	View Revisions
02-01-2013 06:02	Fed	File Added: frm_MarksExplorer.pas
02-01-2013 06:04	Fed	Note Added: 0010291
04-01-2013 15:12	vasketsov	Note Added: 0010316
04-01-2013 15:13	vasketsov	File Added: SAS_MARKS.pdf
04-01-2013 15:29	vasketsov	Assigned To	=> vasketsov
04-01-2013 15:29	vasketsov	Status	new => assigned
04-01-2013 22:44	vasketsov	Note Added: 0010321
05-01-2013 11:11	Fed	Note Added: 0010328
18-01-2013 20:46	vasketsov	File Deleted: frm_MarksExplorer.pas
18-01-2013 20:46	vasketsov	File Deleted: SAS_MARKS.pdf
18-01-2013 20:47	vasketsov	File Added: SAS_MARKS.pdf
13-02-2013 11:02	vasketsov	Project	SAS.Планета => SACS.Планета
13-02-2013 11:10	vasketsov	Status	assigned => resolved
13-02-2013 11:10	vasketsov	Resolution	open => fixed
09-08-2013 15:00	vasketsov	Fixed in Version	=> 130803
09-08-2013 15:13	vasketsov	Status	resolved => closed

Relationships

SASGIS