SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002859SAS.Планета[All Projects] Багpublic16-10-2015 15:5530-12-2021 08:59
Reportersheavy 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformWindowsOS7OS VersionProfessional
Product Version151010 
Target Version25xxxxFixed in Version 
Summary0002859: Редактирование метки, удаленной другим пользователем
Descriptionесли метка была удалена другим пользователем, после сохранения изменений первым пользователем метка пропадает без объяснения причин. Кажется, есть смысл перед сохранением проверить, есть ли она еще в базе и если нет, сообщить об этом пользователю.
Additional Informationпроверялось на MySQL (ODBC), MS SQL (ODBC)
TagsБД, метки, многопользоватеская
Attached Files

- Relationships
related to 0002857resolvedzed Редактирование базы данны меток двумя пользователями 
related to 0003186confirmed Ошибка при многопользовательской работе с базой меток в базе MySql 

-  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 (2698x), 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 2778
Last View 02-07-2022 08:44

- 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 => 25xxxx



Copyright © 2007 - 2022 SAS.Planet Team