powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Версионность // Длинный транзакции // Long transaction
9 сообщений из 9, страница 1 из 1
Версионность // Длинный транзакции // Long transaction
    #38851229
kos2nus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго времени суток.

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

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

Заранее спасибо
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851233
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851234
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kos2nus,
ты куй
куй, и оно пойдёт
например расскажи нам ара, что там в ващемь ара, кале, называется тлл [толстый лысый луи ?] и мы, ара, калоед ты нашЪ, вместе подумаем, чего тебе не хватает
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851238
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk,
если я прально поал -- эти чилавеки должны иметь общую транзакцию. если да -- то это делается в приложении[или третьем слое] -- всех их собираем в одном db-connection, говорим в нем BTGIN; и рулим очередью их запросов. только вот нафигакс это нужно ?

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

кстати удобно было бы, если бы дблинк умел шарить соединение (по глобальному имени, например) -- тогда можно было бы не в третьем слое, а в дблинк-соединении такое сделать.
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851245
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
всё же от лени это у вас всё

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

или у вас пяток групп конкурентно должны это делать, а кто не успел -- того и тапком ?
тады да, тады именно захват снепшота и длинная общая через общее соединение транзакцияю
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851258
kos2nus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
авторвсё же от лени это у вас всё

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

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

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

Если ничего такого нет, то придется конечно делать самому. Я вижу это так: есть основная схема данных (read only). Все измененные данные будут сохраняться в схеме конкретного пользователя. А потом администратор, проверив, будет по очереди применять эти "транзакции" с основной схеме.
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851275
этта
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kos2nus,
ну разоритесь же на аналитика, ять
оно дешевле по итогу будет
и выньте палец изо рта
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851295
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kos2nus...

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

ИМХО проверять надо данные, а не то что в транзакции сделано ( вот удалил я каждую 2-ю строчку а потом вернул 99% из них из своего локального файлика, как найти тот 1% что реально изменились ( удалились ) ;) )...
Просто данные должны иметь пометку, что они не финальные, а финальную отметку должен ставить тот кто за неё будет отвечать. Как это реализовать другой вопрос.
...
Рейтинг: 0 / 0
Версионность // Длинный транзакции // Long transaction
    #38851862
hattifattener
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kos2nus А потом администратор, проверив, будет по очереди применять эти "транзакции" с основной схеме.

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

Возможно вообще нет смысла использовать длинные транзакции, а стоит завести очередь заявок, куда коммитят операторы и которую проверяющий разбирает уже по своей логике на отдельные транзакции.
...
Рейтинг: 0 / 0
9 сообщений из 9, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Версионность // Длинный транзакции // Long transaction
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]