|
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
|
|
|
И если добавлять в модель поле с хэшем, то не понятно что делать со старыми записями в БД. В общем, беда... |
|
|
|
|
> Дело в том, что поле id не автоинкрементное и при вставке вычисляется как "select max(id) from %table_name%".
Это очень плохо. В многопользовательской системе это практически недопустимо. |
|
|
|
(0016586)
|
|
zed
|
|
18-10-2015 19:50
|
|
|
Это делается внутри транзакции, так что особого криминала быть не должно - инсерт просто обломится, если кто-то успеет вставить строку с таким же id. |
|
|
|
|
|
Ну вот вариант редактирования и пересоздания метки отличный контрпример, почему так делать не стоит. А вообще для таких вещей ИМХО оптимальный вариант это использование каких-то 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
|
|
|
И что делать с существующими записями в БД у которых этого поля нет? |
|
|
|
|
> По поводу guid - предлагаешь добавить текстовое поле?
Ну, не то что бы предлагаю делать, а предлагаю рассмотреть такой вариант.
+ версия для записи
+ все операции делать в режиме CompareAndSwap (CAS)
+ добавить поддержку CAS режима в интерфейсы баз меток САСа и его ГУЙ.
Причем раз уж у нас уже есть несколько движков для меток, то никто не заставляет ломать совместимость уже существующих локальных баз. Пусть SQLite и тп живет с той схемой что есть, а серверные СУБД можно потихоньку пилить новую схему в виде отдельного типа баз. |
|
|
|
|
>И что делать с существующими записями в БД у которых этого поля нет?
В локальных базах оно не особо нужно.
А серверные таки придется обновлять схему, но ИМХО тот кто настроил сервер сможет и обновить структуру его таблиц. |
|
|
|
(0016594)
|
|
zed
|
19-10-2015 09:12
(edited on: 19-10-2015 09:13) |
|
>предлагаю рассмотреть такой вариант.
Рассматривать варианты можно когда их предложено несколько. А тут как бы и выбирать не из чего? Можно ещё предложить решение "в лоб": перед инсертом заново считывать все данные из БД и проверять со старой записью в памяти, и если не совпадает хоть одно поле, запрещать обновление. Это тоже самое, что и вариант с версией и guid, но из БД нужно будет считывать гораздо больше. Зато обновлять схему не потребуется.
>сможет и обновить структуру его таблиц
Структуру таблиц движок сам обновит, не в этом вопрос. Но вот после обновления, новые поля нужно будет чем-то заполнить. Предлагаешь заставить всех руками их заполнять?
|
|
|
|
|
> Рассматривать варианты можно когда их предложено несколько.
Подразумевается, что у тебя есть свои мысли и идеи на этот счет. Ты же начал реализацию меток на базе СУБД, должен был уже что-то попробовать, знаешь как ORM работает.
>заново считывать все данные из БД и проверять со старой записью в памяти, и если не совпадает хоть одно поле, запрещать обновление.
Тоже вполне себе вариант. Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток.
>Структуру таблиц движок сам обновит, не в этом вопрос. Но вот после обновления, новые поля нужно будет чем-то заполнить.
Ну, гуид прекрасно делается из существующих ID, а версия просто устанавливается в 1 или в любое ненулевое число, хоть рендомное. |
|
|
|
(0016596)
|
|
zed
|
|
19-10-2015 10:22
|
|
> должен был уже что-то попробовать, знаешь как ORM работает.
Святая наивность :) Ты может забыл - я не программист и образование у меня не it-шное. Моё знакомство с СУБД и ORM происходит у тебя на глазах, в коде SAS. А до этого я точно так же знакомился с Беркли и со всеми прочими штуками.
> Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток.
Как ты это представляешь? Уйти от ORM и сделать СУБД нативно?
В общем, наверное сделаю решение "в лоб" для СУБД и монги, без изменения схемы. Оно хоть и не оптимально будет с точки зрения производительности, но операция редактирования на самом деле должна быть весьма редкая. А с SQLite3 прокатит простая проверка id, т.к. там он таки автоинкрементный. |
|
|
|
|
>> должен был уже что-то попробовать, знаешь как ORM работает.
> Святая наивность :) Ты может забыл - я не программист и образование у меня не it-шное. Моё знакомство с СУБД и ORM происходит у тебя на глазах, в коде SAS. А до этого я точно так же знакомился с Беркли и со всеми прочими штуками.
Ты думаешь, я наю намного больше в этой области?
>> Но я бы все равно посоветовал разделять локальные базы и серверные СУБД на разные типы базы меток.
>Как ты это представляешь? Уйти от ORM и сделать СУБД нативно?
Разделить реализацию на уровне делфийского кода. Так как сейчас различаются SML и SQLite. После чего считать базы в формате SQLite уже стабильным форматом, а метки в СУБД допиливать никому не обещая их совместимость. |
|
|
|
(0016600)
|
|
zed
|
|
19-10-2015 13:19
|
|
|
Сейчас есть SML и ORM, а не SQLite. А чтобы на уровне кода разнести SQLite и СУБД, придётся тупо копипастить и делить ORM пополам. В итоге, получится ORM который только SQLite и ORM, который всё остальное. И там будет до 90% одинакового кода. Ты это предлагаешь? |
|
|
|
|
|
Не важно как это в коде будет выглядить. Пока можно ограничиться булевым параметром в конструкторе фабрики баз меток. Главное что бы пользовтель явно видел, что это локальная база меток, а это подключение к серверу, которое пока работает в тестовом режиме и может понадобиться или грохнуть всю базу, или вручную ее модифицировать при изменении структуры. |
|