iBase.ru Forum

будет ли работать такой триггер?

CREATE TRIGGER ITT for RDB$RELATIONS ACTIVE AFTER INSERT POSITION 32700 AS BEGIN INSERT INTO TTT (NT) VALUES (NEW.RDB$RELATION_NAME); end

Этот триггер должен, как Вы поняли, добавлять имя созданной таблицы в другую таблицу этой же БД? Я думаю, что должен работать, однако если создавать таблицу в IBExpert - он не срабатывает.

и зачем это, интересно?

p.s. никакие навесы на системные таблицы не переживают b/r.

Спасибо за PS.
Тема репликации затрагивает в моем решении список таблиц, но в задаче стоит акцент на том, что репликация может быть отложенной и в ходе работы могут добавляться и удаляться таблицы, здесь необходим список пользовательских таблиц, входящих в БД. Не важно в каком виде, идентификаторы или просто имена, в любом случае список выбирается из RDB$Relations автоматически. В таблице регистрации транзакций, присутствует поле идентификации таблиц. И если добавить какую то таблицу триггер должен добавлять в список имя новой таблице. Таблица может добавляться и удаляться разными способами и средствами - это желание того, кто ставит такие задачи.
Вот представьте, что если в таблице учета транзакций будут записи какой-то таблицы и ее удалить, такой триггер должен удалить из списка таблиц соответствующую таблицу, в которой в свою очередь при удалении записи сработает другой триггер, удаляющий все записи с участием удаляемой таблицы из таблицы учета тразакций.
Не хочу вас грузить, но вопрос состоит в том, куда тогда навешивать триггер на добавление новых и удаление старых таблиц, как ни на RDB$Relations?
В принципе выход может быть еще и в автоматическом навешивании этого триггера сразу после восстановления. Тогда второй вопрос,
почему триггер не работает... Что в нем не правильно?
С уважением...

Часть навесов на системные таблицы не переживают транзакцию, их породившую.

Nat писал(а):в ходе работы могут добавляться и удаляться таблицы

Весело. Позволь узнать область работы такой БД?

Весело. Позволь узнать область работы такой БД?

Уважаемый WildSery, я не могу сказать Вам область работы такой БД... На другие вопросы я отвечу с удовольствием.

Часть навесов на системные таблицы не переживают транзакцию, их породившую

- чем это объясняется? В смысле почему именно часть, а не все. Разве здесь могут быть неоднозначности?
С уважением...

Nat писал(а):

Часть навесов на системные таблицы не переживают транзакцию, их породившую

- чем это объясняется? В смысле почему именно часть, а не все. Разве здесь могут быть неоднозначности?

Что не переживают - тем, что структура системных объектов - это часть понятия ODS. Системные - это системные, то есть предназначенные для нужд системы, а не пользователя. А что часть навесов таки иногда работает некоторое время - ну, в любом софте есть баги, их постепенно изводят.

Спасибо! Но тогда получается нет "правильного" механизма автоматического срабатывания на изменения метаданных? Хотя меня интересует сейчас прежде всего события добавления и удаления таблиц(при этом не интересует изменение метаданных и пользовательских данных самой таблицы).
Sorry! Интересует FB1.5.3

Не хочешь говорить область применения - не надо. Тогда такой вопрос - у тебя объектная база по образцу 1С? Т.е. меняем настройки каких-то "реквизитов" или "объектов", и некий алгоритм строит нужную структуру таблиц под новую объектную конфигурацию?
Кто и зачем создаёт/удаляет таблицы? Или это вообще "временные"?

Не хочешь ... - не надо

Эта информация не принадлежит мне, я не не не хочу, а не могу, извини.
Таблицы будут создавать те, кто просит о таком механизме, система будет дорабатываться, исправляться и т.д. А механизм репликации должен при этом работать безупречно, в виде отдельного процесса или приложения, не суть... Этот же механизм будет отвечать и за б/р, поэтому можно навешивать триггер сразу после восстановления. Но там тоже все не совсем просто, будут проверки на валидность востановления перед переименованием...

А не проще ли хранить контрольный список пользовательских таблиц в "служебной" таблице и при репликации сравнивать с фактическим? и не надо никаких выкрутасов с системными метаданными...

В смысле "соблюдения протокола InterBase" получается, что скорее правильнее, чем проще. Но тогда предполагается некоторая, скорее всего приемлемая задержка, хотя и использованием триггера есть задержка, но эти две задержки несоизмеримы. Хотя в данном вопросе, учитывая многие факторы изменения метаданных, точнее сказать условия, при которых они могут меняться, эта задержка будет приемлемой, заказчик настаивает на решение проблеммы посредством триггерной логики. Мое мнение с Вашим, уважаемый Slavik, совпадает. Заказчик же говорит, если есть лазейка, ее надо использовать. И кажеться я нашел такую лазейку. Триггер на вставку в RDB$Relations типа after, действительно не срабатывает, а вот before, работает и в эксперименте нескольких деятков изменений сбоя ни разу не дал. На удаление after также не дает сбоя.
Я предупредил заказчика, что это может работать по разному, поскольку IB на это гарантии не предоставляет. Тем не менее он настаивает... Пока это всех устраивает, пусть так и будет.
Спасибо всем за обсуждение и мысли.

Имей в виду - разные триггера на разных таблицах работают или не работают по-разному и на разных версиях тоже. Rdb$relations - не единственная системная таблица, за которой надо следить. И b/r не переживают, по-моему, все - структура ODS создаётся, а не ресторится. Закладываться даже не на недокументированные фичи, а на явные баги - путь граблей типа hardcore XXX.

упоминается IB - это требование заказчика? Заказчик готов платить за IB 6.5/7.x/2007, или он идиот, который требует использования IB 6.0?

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

Nat писал(а):В смысле "соблюдения протокола InterBase" получается, что скорее правильнее, чем проще. Но тогда предполагается некоторая, скорее всего приемлемая задержка, хотя и использованием триггера есть задержка, но эти две задержки несоизмеримы. Хотя в данном вопросе, учитывая многие факторы изменения метаданных, точнее сказать условия, при которых они могут меняться, эта задержка будет приемлемой, заказчик настаивает на решение проблеммы посредством триггерной логики.

Не понимаю, о какой задержке идёт речь? Судя по описываемой задаче, информация об изменениях в метаданных нужна в момент запуска репликатора. Дык, он её и получит надёжным способом сравнения. Зачем заранее генерировать эту информацию заведомо ненадёжными способами? Очень велика вероятность косяков, когда плановый бэкап-рестор по каким-то причинам сбойнул, а админ срочно восстанавливая базу вручную забывает прогнать скрипт. Или просто не успевает...

Что-то мне подсказывает, что автору нужно скорее тиражирование чем репликация. Оно обычно более удачно делается методом backup-restore (включая nbackup).

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

упоминается IB - это требование заказчика? Заказчик готов платить за IB 6.5/7.x/2007

Имеется ввиду, что данный вопрос,ИМХО,одинаково решается в IB/FB. Возможно не совсем удачно сказано. Вопрос решается на самом деле в FB 1.5.3
Мои объяснения о том, что такое решение (через триггер к RDB$relations) - мягко сказать не корректно и вообще для чего этот ... нужен вызывают неоднозначную реакцию заказчика, который считает себя умнее, правда как оказалось ничего не слышал о двухфазном подтверждении. Однако настаивает, если что-то получается, пусть даже через ж..у, пусть будет. У нас с ним разногласия по вопросам первичности скорости, качества и надежности, но хозяин в данном случае барин, работать с этим ему, мы с ним никак не прикасаемся по остальным жизненным вопросам.
Это по поводу вашего удивления, к чему все это... если обычно по-другому.
Что касается ситуации b/r, поскольку эта же программа будет производить b/r, то этот триггер можно снять перед b/r и установить сразу после... На этот счет придется еще подумать и поэкспериментировать. У меня нет пока возможности изучить внутренний алгоритм действий IB/FB, хотелось бы конечно однозначно знать, что происходит внутри БД, надеюсь в скором будущем узнать... Пока же я на стадии новорожденного в этих вопросах...
С уважением... ко всем ко ищет и помогает искать истину.

хотелось бы конечно однозначно знать, что происходит внутри БД

что именно узнать-то?

при бэкапе никакие изменения или "дополнения" системных таблиц не бэкапятся.

а restore происходит в 4 этапа:
1. создание пустой БД.
2. заливка пользовательских метаданных (еще раз подчеркиваю, что тут в бэкапе никакие изменения системных таблиц не хранятся)
3. заливка данных
4. создание индексов

то есть, да, единственный вариант восстановления такого триггера - создать его заново после restore. система получается громоздкой и плохо управляемой.

Nat писал(а):сравнение структуры конечно метод, но репликация по заявленному алгоритму может начаться с отсрочкой, а за время отсрочки все изменения во вновь созданных таблицах нужно зафиксировать, кроме того, если таблица наоборот удалена, то и записи о транзакциях в удаленной таблице должны быть удалены до начала репликации.

И в чём проблема? Пусть репликатор этим и занимается...

Nat писал(а):В таком случае сравнение структур перед процессом репликации поможет только при удалении таблиц, при добавлении будет потеряна информация изменений новых таблиц.

Данные из "новых" таблиц прочитать репликатору совесть не позволит?

Каким инструментом заказчик собирается ковырять метаданные? Тем, что под руку подвернётся, или всё же процесс внесения изменений в метаданные как-то будет регламентироваться?

Каким инструментом заказчик собирается ковырять метаданные?

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

Данные из "новых" таблиц прочитать репликатору совесть не позволит?

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

1. не нужно создавать триггеры на системные таблицы.
2. не нужно дублировать создание дополнительных триггеров при b/r
3. не нужно записывать транзакции до репликации в новых таблицах

минусы:

1. придется при каждой репликации сравнивать список пользовательских таблиц
2. придется копировать все данные из новых таблиц в случае обнаружения новой таблицы

Плюсов больше и в таком раскладе не нужно идти против правил...

Уважаемый
kdv Спасибо за разъяснение процесса восстановления...

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

Спасибо большое за ваши мысли и подсказки, за ваше время...
С уважением.