0002859: Редактирование метки, удаленной другим пользователем

Notes
(0016579) sheavy (reporter) 16-10-2015 15:59	начало здесь: http://www.sasgis.org/mantis/view.php?id=2857

(0016581) zed (manager) 18-10-2015 06:13	Да, нужно делать insert вместо update, если метка удалена. При этом id у метки изменится и вероятно из гуя можно будет отследить этот момент и сообщить юзеру, что метка была вставлена, а не изменена.

(0016582) zed (manager) 18-10-2015 12:25 edited on: 18-10-2015 12:26	Ха, интересная вещь получается. Если пользователь удалит и поставит новую метку за то время, пока первый редактирует, то добавленная метка затрётся если делать проверку существования метки по id. Дело в том, что поле id не автоинкрементное и при вставке вычисляется как "select max(id) from %table_name%". Поэтому, чтобы корректно определить не удалилась ли метка из БД, для метки нужно сохранять ещё и её хэш и проверять, что в БД есть такой id с таким-то хэшем. А из этого следует, что надо обновлять модель и гораздо серьёзнее рефакторить код, чтобы пофиксить данный тикет. Или может у кого есть предложение, как это можно сделать проще?

(0016584) zed (manager) 18-10-2015 16:46	И если добавлять в модель поле с хэшем, то не понятно что делать со старыми записями в БД. В общем, беда...

(0016585) vdemidov (manager) 18-10-2015 19:30	> Дело в том, что поле id не автоинкрементное и при вставке вычисляется как "select max(id) from %table_name%". Это очень плохо. В многопользовательской системе это практически недопустимо.

(0016586) zed (manager) 18-10-2015 19:50	Это делается внутри транзакции, так что особого криминала быть не должно - инсерт просто обломится, если кто-то успеет вставить строку с таким же id.

(0016589) vdemidov (manager) 19-10-2015 08:36	Ну вот вариант редактирования и пересоздания метки отличный контрпример, почему так делать не стоит. А вообще для таких вещей ИМХО оптимальный вариант это использование каких-то GUID в качестве ID. Шансов на дубль почти нету, а при размере полигона хотя бы в 10 точек накладные расходы на GUID выглядят копейками. Да и генерить можно ключи без обращения к серверу.

(0016590) zed (manager) 19-10-2015 08:42 edited on: 19-10-2015 08:52	Ну так это делает фреймворк и там есть на то причины. Просто я его использую не совсем так, как это задумывали его создатели. Если следовать рекомендациям, то СУБД и MongoDB из SAS нужно выпилить, потому как эти фишки не рекомендуют использовать из клиентского приложения. По поводу guid - предлагаешь добавить текстовое поле?

(0016591) zed (manager) 19-10-2015 08:51	И что делать с существующими записями в БД у которых этого поля нет?

(0016592) vdemidov (manager) 19-10-2015 08:53	> По поводу guid - предлагаешь добавить текстовое поле? Ну, не то что бы предлагаю делать, а предлагаю рассмотреть такой вариант. + версия для записи + все операции делать в режиме CompareAndSwap (CAS) + добавить поддержку CAS режима в интерфейсы баз меток САСа и его ГУЙ. Причем раз уж у нас уже есть несколько движков для меток, то никто не заставляет ломать совместимость уже существующих локальных баз. Пусть SQLite и тп живет с той схемой что есть, а серверные СУБД можно потихоньку пилить новую схему в виде отдельного типа баз.

(0016593) vdemidov (manager) 19-10-2015 08:55	>И что делать с существующими записями в БД у которых этого поля нет? В локальных базах оно не особо нужно. А серверные таки придется обновлять схему, но ИМХО тот кто настроил сервер сможет и обновить структуру его таблиц.

(0016594) zed (manager) 19-10-2015 09:12 edited on: 19-10-2015 09:13	>предлагаю рассмотреть такой вариант. Рассматривать варианты можно когда их предложено несколько. А тут как бы и выбирать не из чего? Можно ещё предложить решение "в лоб": перед инсертом заново считывать все данные из БД и проверять со старой записью в памяти, и если не совпадает хоть одно поле, запрещать обновление. Это тоже самое, что и вариант с версией и guid, но из БД нужно будет считывать гораздо больше. Зато обновлять схему не потребуется. >сможет и обновить структуру его таблиц Структуру таблиц движок сам обновит, не в этом вопрос. Но вот после обновления, новые поля нужно будет чем-то заполнить. Предлагаешь заставить всех руками их заполнять?

(0016595) vdemidov (manager) 19-10-2015 09:58	> Рассматривать варианты можно когда их предложено несколько. Подразумевается, что у тебя есть свои мысли и идеи на этот счет. Ты же начал реализацию меток на базе СУБД, должен был уже что-то попробовать, знаешь как ORM работает. >заново считывать все данные из БД и проверять со старой записью в памяти, и если не совпадает хоть одно поле, запрещать обновление. Тоже вполне себе вариант. Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток. >Структуру таблиц движок сам обновит, не в этом вопрос. Но вот после обновления, новые поля нужно будет чем-то заполнить. Ну, гуид прекрасно делается из существующих ID, а версия просто устанавливается в 1 или в любое ненулевое число, хоть рендомное.

(0016596) zed (manager) 19-10-2015 10:22	> должен был уже что-то попробовать, знаешь как ORM работает. Святая наивность :) Ты может забыл - я не программист и образование у меня не it-шное. Моё знакомство с СУБД и ORM происходит у тебя на глазах, в коде SAS. А до этого я точно так же знакомился с Беркли и со всеми прочими штуками. > Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток. Как ты это представляешь? Уйти от ORM и сделать СУБД нативно? В общем, наверное сделаю решение "в лоб" для СУБД и монги, без изменения схемы. Оно хоть и не оптимально будет с точки зрения производительности, но операция редактирования на самом деле должна быть весьма редкая. А с SQLite3 прокатит простая проверка id, т.к. там он таки автоинкрементный.

(0016599) vdemidov (manager) 19-10-2015 13:09	>> должен был уже что-то попробовать, знаешь как ORM работает. > Святая наивность :) Ты может забыл - я не программист и образование у меня не it-шное. Моё знакомство с СУБД и ORM происходит у тебя на глазах, в коде SAS. А до этого я точно так же знакомился с Беркли и со всеми прочими штуками. Ты думаешь, я наю намного больше в этой области? >> Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток. >Как ты это представляешь? Уйти от ORM и сделать СУБД нативно? Разделить реализацию на уровне делфийского кода. Так как сейчас различаются SML и SQLite. После чего считать базы в формате SQLite уже стабильным форматом, а метки в СУБД допиливать никому не обещая их совместимость.

(0016600) zed (manager) 19-10-2015 13:19	Сейчас есть SML и ORM, а не SQLite. А чтобы на уровне кода разнести SQLite и СУБД, придётся тупо копипастить и делить ORM пополам. В итоге, получится ORM который только SQLite и ORM, который всё остальное. И там будет до 90% одинакового кода. Ты это предлагаешь?

(0016601) vdemidov (manager) 19-10-2015 15:33	Не важно как это в коде будет выглядить. Пока можно ограничиться булевым параметром в конструкторе фабрики баз меток. Главное что бы пользовтель явно видел, что это локальная база меток, а это подключение к серверу, которое пока работает в тестовом режиме и может понадобиться или грохнуть всю базу, или вручную ее модифицировать при изменении структуры.

Users who viewed this issue
User List	Anonymous (3670x), stepanxxx (1x), iglezz (1x), ingener (1x), QDeathNick (1x), RedRat (1x), vdemidov (31x), hrucker (1x), fraemos (1x), ygorigor (1x), zed (33x), sheavy (6x), Papazol (1x), ivit (1x), Tolik (1x)
Total Views	3751
Last View	21-11-2024 09:30

Issue History
Date Modified	Username	Field	Change
16-10-2015 15:55	sheavy	New Issue
16-10-2015 15:58	sheavy	Tag Attached: БД
16-10-2015 15:58	sheavy	Tag Attached: метки
16-10-2015 15:58	sheavy	Tag Attached: многопользоватеская
16-10-2015 15:59	sheavy	Note Added: 0016579
16-10-2015 16:32	vdemidov	Relationship added	related to 0002857
18-10-2015 06:13	zed	Note Added: 0016581
18-10-2015 06:13	zed	Status	new => confirmed
18-10-2015 06:14	zed	Product Version	.Nightly => 151010
18-10-2015 06:14	zed	Target Version	=> 151111
18-10-2015 12:25	zed	Note Added: 0016582
18-10-2015 12:26	zed	Note Edited: 0016582	View Revisions
18-10-2015 16:46	zed	Note Added: 0016584
18-10-2015 19:30	vdemidov	Note Added: 0016585
18-10-2015 19:50	zed	Note Added: 0016586
19-10-2015 08:36	vdemidov	Note Added: 0016589
19-10-2015 08:42	zed	Note Added: 0016590
19-10-2015 08:51	zed	Note Added: 0016591
19-10-2015 08:52	zed	Note Edited: 0016590	View Revisions
19-10-2015 08:53	vdemidov	Note Added: 0016592
19-10-2015 08:55	vdemidov	Note Added: 0016593
19-10-2015 09:12	zed	Note Added: 0016594
19-10-2015 09:13	zed	Note Edited: 0016594	View Revisions
19-10-2015 09:58	vdemidov	Note Added: 0016595
19-10-2015 10:22	zed	Note Added: 0016596
19-10-2015 13:09	vdemidov	Note Added: 0016599
19-10-2015 13:19	zed	Note Added: 0016600
19-10-2015 15:33	vdemidov	Note Added: 0016601
06-11-2015 08:19	vdemidov	Target Version	151111 => 191221
03-03-2017 09:07	vdemidov	Relationship added	related to 0003186
23-07-2019 17:04	vdemidov	Target Version	191221 => 211230
30-12-2021 08:59	zed	Target Version	211230 => 26xxxx

SASGIS