SASGIS - SAS.Планета
View Issue Details
0002859SAS.Планета[All Projects] Багpublic16-10-2015 15:5530-12-2021 08:59
sheavy 
 
normalminoralways
confirmedopen 
Windows7Professional
151010 
26xxxx 
0002859: Редактирование метки, удаленной другим пользователем
если метка была удалена другим пользователем, после сохранения изменений первым пользователем метка пропадает без объяснения причин. Кажется, есть смысл перед сохранением проверить, есть ли она еще в базе и если нет, сообщить об этом пользователю.
проверялось на MySQL (ODBC), MS SQL (ODBC)
БД, метки, многопользоватеская
related to 0002857resolved zed Редактирование базы данны меток двумя пользователями 
related to 0003186confirmed  Ошибка при многопользовательской работе с базой меток в базе MySql 
Issue History
16-10-2015 15:55sheavyNew Issue
16-10-2015 15:58sheavyTag Attached: БД
16-10-2015 15:58sheavyTag Attached: метки
16-10-2015 15:58sheavyTag Attached: многопользоватеская
16-10-2015 15:59sheavyNote Added: 0016579
16-10-2015 16:32vdemidovRelationship addedrelated to 0002857
18-10-2015 06:13zedNote Added: 0016581
18-10-2015 06:13zedStatusnew => confirmed
18-10-2015 06:14zedProduct Version.Nightly => 151010
18-10-2015 06:14zedTarget Version => 151111
18-10-2015 12:25zedNote Added: 0016582
18-10-2015 12:26zedNote Edited: 0016582bug_revision_view_page.php?bugnote_id=16582#r6743
18-10-2015 16:46zedNote Added: 0016584
18-10-2015 19:30vdemidovNote Added: 0016585
18-10-2015 19:50zedNote Added: 0016586
19-10-2015 08:36vdemidovNote Added: 0016589
19-10-2015 08:42zedNote Added: 0016590
19-10-2015 08:51zedNote Added: 0016591
19-10-2015 08:52zedNote Edited: 0016590bug_revision_view_page.php?bugnote_id=16590#r6747
19-10-2015 08:53vdemidovNote Added: 0016592
19-10-2015 08:55vdemidovNote Added: 0016593
19-10-2015 09:12zedNote Added: 0016594
19-10-2015 09:13zedNote Edited: 0016594bug_revision_view_page.php?bugnote_id=16594#r6749
19-10-2015 09:58vdemidovNote Added: 0016595
19-10-2015 10:22zedNote Added: 0016596
19-10-2015 13:09vdemidovNote Added: 0016599
19-10-2015 13:19zedNote Added: 0016600
19-10-2015 15:33vdemidovNote Added: 0016601
06-11-2015 08:19vdemidovTarget Version151111 => 191221
03-03-2017 09:07vdemidovRelationship addedrelated to 0003186
23-07-2019 17:04vdemidovTarget Version191221 => 211230
30-12-2021 08:59zedTarget Version211230 => 26xxxx

Notes
(0016579)
sheavy   
16-10-2015 15:59   
начало здесь: http://www.sasgis.org/mantis/view.php?id=2857
(0016581)
zed   
18-10-2015 06:13   
Да, нужно делать insert вместо update, если метка удалена. При этом id у метки изменится и вероятно из гуя можно будет отследить этот момент и сообщить юзеру, что метка была вставлена, а не изменена.
(0016582)
zed   
18-10-2015 12:25   
(edited on: 18-10-2015 12:26)
Ха, интересная вещь получается. Если пользователь удалит и поставит новую метку за то время, пока первый редактирует, то добавленная метка затрётся если делать проверку существования метки по id. Дело в том, что поле id не автоинкрементное и при вставке вычисляется как "select max(id) from %table_name%". Поэтому, чтобы корректно определить не удалилась ли метка из БД, для метки нужно сохранять ещё и её хэш и проверять, что в БД есть такой id с таким-то хэшем.

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

Или может у кого есть предложение, как это можно сделать проще?

(0016584)
zed   
18-10-2015 16:46   
И если добавлять в модель поле с хэшем, то не понятно что делать со старыми записями в БД. В общем, беда...
(0016585)
vdemidov   
18-10-2015 19:30   
> Дело в том, что поле id не автоинкрементное и при вставке вычисляется как "select max(id) from %table_name%".
Это очень плохо. В многопользовательской системе это практически недопустимо.
(0016586)
zed   
18-10-2015 19:50   
Это делается внутри транзакции, так что особого криминала быть не должно - инсерт просто обломится, если кто-то успеет вставить строку с таким же id.
(0016589)
vdemidov   
19-10-2015 08:36   
Ну вот вариант редактирования и пересоздания метки отличный контрпример, почему так делать не стоит. А вообще для таких вещей ИМХО оптимальный вариант это использование каких-то GUID в качестве ID. Шансов на дубль почти нету, а при размере полигона хотя бы в 10 точек накладные расходы на GUID выглядят копейками. Да и генерить можно ключи без обращения к серверу.
(0016590)
zed   
19-10-2015 08:42   
(edited on: 19-10-2015 08:52)
Ну так это делает фреймворк и там есть на то причины. Просто я его использую не совсем так, как это задумывали его создатели. Если следовать рекомендациям, то СУБД и MongoDB из SAS нужно выпилить, потому как эти фишки не рекомендуют использовать из клиентского приложения.

По поводу guid - предлагаешь добавить текстовое поле?

(0016591)
zed   
19-10-2015 08:51   
И что делать с существующими записями в БД у которых этого поля нет?
(0016592)
vdemidov   
19-10-2015 08:53   
> По поводу guid - предлагаешь добавить текстовое поле?
Ну, не то что бы предлагаю делать, а предлагаю рассмотреть такой вариант.
+ версия для записи
+ все операции делать в режиме CompareAndSwap (CAS)
+ добавить поддержку CAS режима в интерфейсы баз меток САСа и его ГУЙ.
Причем раз уж у нас уже есть несколько движков для меток, то никто не заставляет ломать совместимость уже существующих локальных баз. Пусть SQLite и тп живет с той схемой что есть, а серверные СУБД можно потихоньку пилить новую схему в виде отдельного типа баз.
(0016593)
vdemidov   
19-10-2015 08:55   
>И что делать с существующими записями в БД у которых этого поля нет?
В локальных базах оно не особо нужно.
А серверные таки придется обновлять схему, но ИМХО тот кто настроил сервер сможет и обновить структуру его таблиц.
(0016594)
zed   
19-10-2015 09:12   
(edited on: 19-10-2015 09:13)
>предлагаю рассмотреть такой вариант.
Рассматривать варианты можно когда их предложено несколько. А тут как бы и выбирать не из чего? Можно ещё предложить решение "в лоб": перед инсертом заново считывать все данные из БД и проверять со старой записью в памяти, и если не совпадает хоть одно поле, запрещать обновление. Это тоже самое, что и вариант с версией и guid, но из БД нужно будет считывать гораздо больше. Зато обновлять схему не потребуется.

>сможет и обновить структуру его таблиц
Структуру таблиц движок сам обновит, не в этом вопрос. Но вот после обновления, новые поля нужно будет чем-то заполнить. Предлагаешь заставить всех руками их заполнять?

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

>заново считывать все данные из БД и проверять со старой записью в памяти, и если не совпадает хоть одно поле, запрещать обновление.
Тоже вполне себе вариант. Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток.

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

> Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток.
Как ты это представляешь? Уйти от ORM и сделать СУБД нативно?

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

>> Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток.
>Как ты это представляешь? Уйти от ORM и сделать СУБД нативно?
Разделить реализацию на уровне делфийского кода. Так как сейчас различаются SML и SQLite. После чего считать базы в формате SQLite уже стабильным форматом, а метки в СУБД допиливать никому не обещая их совместимость.
(0016600)
zed   
19-10-2015 13:19   
Сейчас есть SML и ORM, а не SQLite. А чтобы на уровне кода разнести SQLite и СУБД, придётся тупо копипастить и делить ORM пополам. В итоге, получится ORM который только SQLite и ORM, который всё остальное. И там будет до 90% одинакового кода. Ты это предлагаешь?
(0016601)
vdemidov   
19-10-2015 15:33   
Не важно как это в коде будет выглядить. Пока можно ограничиться булевым параметром в конструкторе фабрики баз меток. Главное что бы пользовтель явно видел, что это локальная база меток, а это подключение к серверу, которое пока работает в тестовом режиме и может понадобиться или грохнуть всю базу, или вручную ее модифицировать при изменении структуры.