Версионность // Длинный транзакции // Long transaction

Доброго времени суток.

Подскажите существует ли у Postgres механизм подобный Oracle TLL? Так называемые длинные транзакции? Я так понял что нативно нет. Поиск каких то сторонних плагинов пока так же результата не дал?

Немного поясню для чего конкретно мне такой функционал. К примеру есть ГИС система, которую редактируют несколько человек. Так вот после процесса редактирования, измененные данные должны быть проверены прежде чем буду применены.

Заранее спасибо

kos2nus

Доброго времени суток. Подскажите существует ли у Postgres механизм подобный Oracle TLL? Так называемые длинные транзакции? Я так понял что нативно нет. Поиск каких то сторонних плагинов пока так же результата не дал? Немного поясню для чего конкретно мне такой функционал. К примеру есть ГИС система, которую редактируют несколько человек. Так вот после процесса редактирования, измененные данные должны быть проверены прежде чем буду применены. Заранее спасибо

Нет такой функциональности нет (и не планируется... уж больно специфическое требование)
Такое лучше на уровне приложения делать если надо под PostgreSQL.

Можно попробовать поиграться с http://www.postgresql.org/docs/9.4/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION (использование snapshot для нескольких транзакций) но применять изменения всеравно прийдется в основной транзакции.

--Maxim Boguk
www.postgresql-consulting.ru

kos2nus,
ты куй
куй, и оно пойдёт
например расскажи нам ара, что там в ващемь ара, кале, называется тлл [толстый лысый луи ?] и мы, ара, калоед ты нашЪ, вместе подумаем, чего тебе не хватает

Maxim Boguk,
если я прально поал -- эти чилавеки должны иметь общую транзакцию. если да -- то это делается в приложении[или третьем слое] -- всех их собираем в одном db-connection, говорим в нем BTGIN; и рулим очередью их запросов. только вот нафигакс это нужно ?

можно ещё всем набрасывать времянки, а одному коммитить все изменения в постоянку, но надо ли оно ?

кстати удобно было бы, если бы дблинк умел шарить соединение (по глобальному имени, например) -- тогда можно было бы не в третьем слое, а в дблинк-соединении такое сделать.

всё же от лени это у вас всё

по чесноку надо делать набор постоянных объектов "изменения" с id этого изменения, и люди должны работать в коротких транзакциях с ними, с объектной моделью "изменений".
и даже не завершенные сегодня (до обеда) , но уже сделанные "изменения" должны сохраняться на завтра (на после обеда). а вот коммитить "изменение id такое-то" должны специальные операции.
где то тут аналитицки порыться надо.

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

автор

всё же от лени это у вас всё по чесноку надо делать набор постоянных объектов "изменения" с id этого изменения, и люди должны работать в коротких транзакциях с ними, с объектной моделью "изменений". и даже не завершенные сегодня (до обеда) , но уже сделанные "изменения" должны сохраняться на завтра (на после обеда). а вот коммитить "изменение id такое-то" должны специальные операции. где то тут аналитицки порыться надо. или у вас пяток групп конкурентно должны это делать, а кто не успел -- того и тапком ? тады да, тады именно захват снепшота и длинная общая через общее соединение транзакцияю

не с первого раза конечно, но я смог это прочитать. В принципе это то что надо

Люди работают с базой. Производят изменения, но эти изменения не применяются к тому набору данных с которым работают а сохраняются где то еще до проверки. А что не правильно понял, что подобный механизм называется long transactions?

Если ничего такого нет, то придется конечно делать самому. Я вижу это так: есть основная схема данных (read only). Все измененные данные будут сохраняться в схеме конкретного пользователя. А потом администратор, проверив, будет по очереди применять эти "транзакции" с основной схеме.

kos2nus,
ну разоритесь же на аналитика, ять
оно дешевле по итогу будет
и выньте палец изо рта

kos2nus
... Если ничего такого нет, то придется конечно делать самому. Я вижу это так: есть основная схема данных (read only). Все измененные данные будут сохраняться в схеме конкретного пользователя. А потом администратор, проверив, будет по очереди применять эти "транзакции" с основной схеме.

ИМХО проверять надо данные, а не то что в транзакции сделано ( вот удалил я каждую 2-ю строчку а потом вернул 99% из них из своего локального файлика, как найти тот 1% что реально изменились ( удалились ) ;) )...
Просто данные должны иметь пометку, что они не финальные, а финальную отметку должен ставить тот кто за неё будет отвечать. Как это реализовать другой вопрос.

kos2nus
А потом администратор, проверив, будет по очереди применять эти "транзакции" с основной схеме.

Очереди тоже можно делать по разному - последовательно по операторам или по объектам например. Утверждать каждое изменение в порядке внесения или кумулятивно по объекту за период.
Так что оптимальная схема будет зависеть от режима работы операторов и проверяющего.

Возможно вообще нет смысла использовать длинные транзакции, а стоит завести очередь заявок, куда коммитят операторы и которую проверяющий разбирает уже по своей логике на отдельные транзакции.