Dimitry SibiryakovСабж в тройке это, конечно, крутоЧто-то прошляпил я эту тему. Интересное дело, кажется.
В где найти пример их использования ?

kdvперечитай топик.Перечитал. У мну не так:

Что такое фраза "Replication of transaction 114 initiated", которая лезет в стартовом посте сразу после select "gen_id(gen_t_log,1) from rdb$database;" ?
Что такое вообще "транзакционные генераторы" и в где про них почитать ?

вах.... хренасе... :-)

kdv,

дык теперь уж и не знаю... :-)

dimitrнет уж, ты сначала определись ! :-)Так тут сплошное уравнение неопределённости, возможно даже - по Гейзенбергу!
А если без шуток, то:
1) оч хотелось бы внутри транзакции иметь некий счетчик, известный только ей, стартующий при её старте, с нуля, и ведущий себя как генератор; rdb$get/set_context'ы - очевидное решение, то тормознутое на cast'ах. Проверено. И даже в личку кое-кому было отправлено :-)
2) касательно примера выше - непонятно, ЗАЧЕМ так сделано. Почему set autoddl off вдруг так "завлиял". Ведь я могу приконнектиться к базе isql'ем, причём только с правом обращения к к-л генератору, ввести далее то, что показано - и что будут видеть остальные коннекты ? особливо весело будет, когда я коммит сделаю...

dimitrСильно упертые могут продолжать выкручиваться с нестандартными инкрементами в GEN_ID.Конечно могут. И будут, ибо страница генераторов - одно из узких мест. Если сделать внутри цикла раздачу ИДшников из заранее полученного "пула" (через вызов gen_id( g, :N ), где N >> 1), то будет как в рекламе: "почувствуйте разницу".

dimitr3) В результате впервые в ФБ появляется транзакционный DDL - можно в одной и той же транзакции создать генератор и использовать его, а потом либо грохнуть либо закоммитить.Это всё прекрасно, только как в двух транзакциях создать генератор-"времянку" с одинаковым именем (просто чтобы посчитать им чего-то там, и грохнуть затем) ?
Не получится это. А раз так, то придется делать какой-то изврат типа создания генератора с именем, в которое будет включен номер текущей транзакции. А дальше - выполнять gen_id( имя, 1 ), но ведь его тогда уже и не выполнить в "явном" виде, только через ES.

Гемор какой-то! Поэтому я проголосовал за CORE-4001. Нужен какой-то "локальный счетчик", видимый только в PSQL, никаким боком не отражающийся в метаданных. А еще лучше - структуры такого типа, но это уже фантазии, я понимаю :-)

dimitrЕсли "локальный" (видимый только текущей транзакции), то при коммите при неудачном раскладе мы потеряем только чужие изменения.Что-то непонятно, про какие "чужие" изменения тут речь. Ведь никто не видит мой новосозданный генератор, пока я не ввёл commit.

dimitr5) Явно изменять значения генераторов "на лету" при активной работе с базой - ахтунг. Делать это еще и в длинных транзакциях с GEN_ID внутри - дважды ахтунг. Кто на это нарвется в продакшене - ССЗБ.Нельзя менять в сторону уменьшения. Что плохого в увеличении на шаг N >> 1 для получения "пула" ИДшников - не ведаю. Я этим хаком получил только плюсы, и значительные.

Симонов Денис
у мну пока нет циклов с таким числом итераций... не дорос еще как бэ...

Симонов Денисв сторону увеличения тоже траблы могут бытьЭто "слишком смелое" увеличение. Примерно как то, которое об столб ломается, когда "с дуру"

AriochНо если когда оно станет актуально, про него могут просто не вспомнитьПереход счетчика через 2^63-1 придется долго ждать, если двигаться к нему с шагом = 1. Даже если будут системы со 100 млн транзакциями в секунду... PS. "Через 30 лет другие коммунисты ответят перед партией!" (С) к/ф "Зеркало для героя", 1987.