Dimitry Sibiryakov3) Т3 увидит изменения Т2, а Т4 увидит изменения Т1 И Т2
все вроде штатно. Т4 увидит изменения Т1 И Т2 потому что Т1 и Т2 завершились до старта Т4. Или я чего то не понял?
Почему Т3 не должна увидеть изменений Т2, или Т4 не должна увидеть изменений Т2?

Я бы еще понял вопрос, что будет с изменениями, которые были сделаны и закоммичены во время работы Т3 и Т4. Но и тут есть ответ - при commit подписки сохраняются изменения, сделанные с момента старта транзакции, которая получала подписку.

Dimitry SibiryakovPPS: Какой план даёт чтение изменений я стараюсь не думать.
х.з., не проверял. наверное, ты хотел спросить, какой результат будет при чтении изменений с where? :-)

Dimitry SibiryakovПотому что их уже вычитала Т3 и закоммитилась.
а, понял.

Тогда подписка Т4 увидит только изменения Т1, потому что действительно, изменения в Т2 уже вычитаны подпиской в Т3.

То есть, твой пункт 1.

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

Dimitry Sibiryakovспособ которым они такого эффекта достигают.
эээ, ну ведь известны номера транзакций, и т.д.

тут еще вот в чем фокус. чтобы подписка вообще "началась", ее нужно активировать. Поэтому, собственно, в твоем сценарии, если подписка N, упоминаемая в Т3, ни разу до этого не активировалась, то никаких изменений она не увидит. Потому что она началась только в Т3.
Извиняюсь, если ввел в заблуждение. изменения отслеживаются только с момента первой активации подписки

Так что ответ на твой сценарий (и если в Т3 и Т4 подписка от одного и того же пользователя), это
- Т3 не увидит изменений Т2, поскольку они были совершены до момента активации подписки
- Т4 увидит изменения Т1, потому что они были произведены с момента начала Т3 (в которой подписка была активирована).

Dimitry Sibiryakov,

ну тогда подписка в Т3 увидит изменения в Т2. А подписка в Т4 увидит изменения с момента начала транзакции Т3.

Dimitry Sibiryakov,

В ХЕ7 не так.
Подписка - это что-то типа view, в котором прописано какие таблицы надо отслеживать, какие столбцы, и какие действия.
пользователю выдаются права на конкретную подписку
Далее пользователь может активировать подписку, причем обязательно указывая некое имя (типа "устройство"), откуда он получает изменения по этой подписке.
Так что у одного юзера может быть несколько подписок - на мобиле, в офисе, дома и т.п.

Что касается видимости, то
- юзер получает изменения, произошедшие с момента активации подписки. Получает он их в транзакции snapshot. commit в этой транзакции сигнализирует о том, что юзер получил все изменения, которые произошли ДО СТАРТА этой snapshot-транзакции.
А чтобы активировать подписку и сидеть ждать изменений, нужно сделать
subscription active
тут можно даже inactive сделать
rollback

то есть, активация-деактивация подписки вместе с commit/rollback определяет, что будет дальше с этой подпиской - активна или нет, получаем изменения или смотрим реальные данные. Выключается подписка только по inactive+commit;

Dimitry SibiryakovТо есть изменения, полученные для одного устройства будут уже не видны для этого же
устройства, но для других устройств они будут всё ещё видны?
идентификатором подписчика является Имя_пользователя[+имя_устройства].



указание at - необязательное.

NikolayV81с какого момента начинается логирование наличия изменений?
Со старта транзакции в которой :
set SUBSCRIPTION <subscription_name> AT <destination> ACTIVE
COMMIT;
вроде как невозможно, т.к. журнала нет и придётся привентивно все изменения с момента старта любой транзакии помнить

ыыыы...
set subscription active включает отслеживание изменений, которые были с момента старта транзакции, в которой было вот это active.
при этом commit сигнализирует о том, что изменения, которые были до старта этой транзакции, уже получены.
Чтобы отслеживать изменения дальше, и после завершения транзакции, надо сделать rollback.
active
rollback

я выше об этом писал 2 раза. в rdb$subscribers запоминаются параметры транзакции, с которой нужно отслеживать изменения. Они меняются на текущую транзакцию по commit. чтобы их не менять, т.е. оставить стартом исходную транзакцию с первым active, нужно сделать rollback.

далее, active/inactive меняют вывод операторов. После inactive выводятся все существующие данные. после active - только измененные с момента начала отслеживания подписки.

Еще более популярно.

1. коннект
2. стартуем снапшот
3. получаем обычные данные
4. set subs active
5. получаем изменения, с момента первого active/rollback или последнего active/commit

теперь, допустим, делаем
6. rollback (подписка остается активной, даже если сделать inactive, т.к. изменения мы не получили)
7. disconnect
8. connect
9. старт транзакции
10. тут мы получаем ОБЫЧНЫЕ данные. Потому что сервер в этот момент не имеет понятия, что мы - это мы, и у нас активна подписка. Вернее, он может догадаться, что мы - это мы, но это ему не нужно.
11. set subs active
12. ура, видим те же изменения, что получали в пункте 5.
13. нам надоели изменения, делаем inactive
14.1. теперь, если тут сделать rollback, то все можно повторить с пункта 7, и мы в пункте 12 увидим те же изменения
14.2. если тут сделать commit, подписка прекратит отслеживать изменения. если же не было пункта 13, то подписка останется активной, но в следующий раз мы будем видеть только те изменения, которые произошли с момента пункта 9.

Dimitry SibiryakovЯ так и думал, что они кусок TIP-а в блоб загоняют...
там и tip, и еще туча сохраненных маркеров, причем, часть из них вроде как на будущее, или я пока не понял, зачем.

NikolayV81а как определяется что запись удалена (она же физически отсутсвует)?
удаление записи в версионнике - это создание новой версии. Версия просто содержит признак удаления, а не измененные столбцы, как при update.
В snapshot ты же видишь удаленные другими транзакциями записи во время этого снапшота? Потому что продолжают существовать удаленная "версия/запись" и версия с признаком удаления.

Я ведь писал, что активация подписки замораживает сборку мусора. А модифицированный движок сервера дает возможность увидеть не только что было модифицировано или добавлено, но и что было удалено.
То есть, активная подписка превращается в нечто вроде долгоживущего снапшота, со всеми вытекающими последствиями в виде накопления версий, правда, только для тех объектов и действий, которые указаны в подписке, а не для всех таблиц БД.

NikolayV81,

проще всего пример с insert. Если активация подписки произошла в транзакции 1000, значит для вытаскивания изменений с момента активации такой подписки достаточно выбрать все версии, у которых transaction id >=1000.
Для update - то же самое. Для delete - ищем версии с delete stub >=1000, показываем предыдущую версию.

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