почему триггер к системной таблице не работает...
почему триггер к системной таблице не работает...
будет ли работать такой триггер?
CREATE TRIGGER ITT for RDB$RELATIONS ACTIVE AFTER INSERT POSITION 32700 AS BEGIN INSERT INTO TTT (NT) VALUES (NEW.RDB$RELATION_NAME); end
Этот триггер должен, как Вы поняли, добавлять имя созданной таблицы в другую таблицу этой же БД? Я думаю, что должен работать, однако если создавать таблицу в IBExpert - он не срабатывает.
CREATE TRIGGER ITT for RDB$RELATIONS ACTIVE AFTER INSERT POSITION 32700 AS BEGIN INSERT INTO TTT (NT) VALUES (NEW.RDB$RELATION_NAME); end
Этот триггер должен, как Вы поняли, добавлять имя созданной таблицы в другую таблицу этой же БД? Я думаю, что должен работать, однако если создавать таблицу в IBExpert - он не срабатывает.
Спасибо за PS.
Тема репликации затрагивает в моем решении список таблиц, но в задаче стоит акцент на том, что репликация может быть отложенной и в ходе работы могут добавляться и удаляться таблицы, здесь необходим список пользовательских таблиц, входящих в БД. Не важно в каком виде, идентификаторы или просто имена, в любом случае список выбирается из RDB$Relations автоматически. В таблице регистрации транзакций, присутствует поле идентификации таблиц. И если добавить какую то таблицу триггер должен добавлять в список имя новой таблице. Таблица может добавляться и удаляться разными способами и средствами - это желание того, кто ставит такие задачи.
Вот представьте, что если в таблице учета транзакций будут записи какой-то таблицы и ее удалить, такой триггер должен удалить из списка таблиц соответствующую таблицу, в которой в свою очередь при удалении записи сработает другой триггер, удаляющий все записи с участием удаляемой таблицы из таблицы учета тразакций.
Не хочу вас грузить, но вопрос состоит в том, куда тогда навешивать триггер на добавление новых и удаление старых таблиц, как ни на RDB$Relations?
В принципе выход может быть еще и в автоматическом навешивании этого триггера сразу после восстановления. Тогда второй вопрос,
почему триггер не работает... Что в нем не правильно?
С уважением...
Тема репликации затрагивает в моем решении список таблиц, но в задаче стоит акцент на том, что репликация может быть отложенной и в ходе работы могут добавляться и удаляться таблицы, здесь необходим список пользовательских таблиц, входящих в БД. Не важно в каком виде, идентификаторы или просто имена, в любом случае список выбирается из RDB$Relations автоматически. В таблице регистрации транзакций, присутствует поле идентификации таблиц. И если добавить какую то таблицу триггер должен добавлять в список имя новой таблице. Таблица может добавляться и удаляться разными способами и средствами - это желание того, кто ставит такие задачи.
Вот представьте, что если в таблице учета транзакций будут записи какой-то таблицы и ее удалить, такой триггер должен удалить из списка таблиц соответствующую таблицу, в которой в свою очередь при удалении записи сработает другой триггер, удаляющий все записи с участием удаляемой таблицы из таблицы учета тразакций.
Не хочу вас грузить, но вопрос состоит в том, куда тогда навешивать триггер на добавление новых и удаление старых таблиц, как ни на RDB$Relations?
В принципе выход может быть еще и в автоматическом навешивании этого триггера сразу после восстановления. Тогда второй вопрос,
почему триггер не работает... Что в нем не правильно?
С уважением...
Уважаемый WildSery, я не могу сказать Вам область работы такой БД... На другие вопросы я отвечу с удовольствием.Весело. Позволь узнать область работы такой БД?
- чем это объясняется? В смысле почему именно часть, а не все. Разве здесь могут быть неоднозначности?Часть навесов на системные таблицы не переживают транзакцию, их породившую
С уважением...
Что не переживают - тем, что структура системных объектов - это часть понятия ODS. Системные - это системные, то есть предназначенные для нужд системы, а не пользователя. А что часть навесов таки иногда работает некоторое время - ну, в любом софте есть баги, их постепенно изводят.Nat писал(а):- чем это объясняется? В смысле почему именно часть, а не все. Разве здесь могут быть неоднозначности?Часть навесов на системные таблицы не переживают транзакцию, их породившую
Спасибо! Но тогда получается нет "правильного" механизма автоматического срабатывания на изменения метаданных? Хотя меня интересует сейчас прежде всего события добавления и удаления таблиц(при этом не интересует изменение метаданных и пользовательских данных самой таблицы).
Sorry! Интересует FB1.5.3
Sorry! Интересует FB1.5.3
Не хочешь говорить область применения - не надо. Тогда такой вопрос - у тебя объектная база по образцу 1С? Т.е. меняем настройки каких-то "реквизитов" или "объектов", и некий алгоритм строит нужную структуру таблиц под новую объектную конфигурацию?
Кто и зачем создаёт/удаляет таблицы? Или это вообще "временные"?
Кто и зачем создаёт/удаляет таблицы? Или это вообще "временные"?
Эта информация не принадлежит мне, я не не не хочу, а не могу, извини.Не хочешь ... - не надо
Таблицы будут создавать те, кто просит о таком механизме, система будет дорабатываться, исправляться и т.д. А механизм репликации должен при этом работать безупречно, в виде отдельного процесса или приложения, не суть... Этот же механизм будет отвечать и за б/р, поэтому можно навешивать триггер сразу после восстановления. Но там тоже все не совсем просто, будут проверки на валидность востановления перед переименованием...
В смысле "соблюдения протокола InterBase" получается, что скорее правильнее, чем проще. Но тогда предполагается некоторая, скорее всего приемлемая задержка, хотя и использованием триггера есть задержка, но эти две задержки несоизмеримы. Хотя в данном вопросе, учитывая многие факторы изменения метаданных, точнее сказать условия, при которых они могут меняться, эта задержка будет приемлемой, заказчик настаивает на решение проблеммы посредством триггерной логики. Мое мнение с Вашим, уважаемый Slavik, совпадает. Заказчик же говорит, если есть лазейка, ее надо использовать. И кажеться я нашел такую лазейку. Триггер на вставку в RDB$Relations типа after, действительно не срабатывает, а вот before, работает и в эксперименте нескольких деятков изменений сбоя ни разу не дал. На удаление after также не дает сбоя.
Я предупредил заказчика, что это может работать по разному, поскольку IB на это гарантии не предоставляет. Тем не менее он настаивает... Пока это всех устраивает, пусть так и будет.
Спасибо всем за обсуждение и мысли.
Я предупредил заказчика, что это может работать по разному, поскольку IB на это гарантии не предоставляет. Тем не менее он настаивает... Пока это всех устраивает, пусть так и будет.
Спасибо всем за обсуждение и мысли.
Имей в виду - разные триггера на разных таблицах работают или не работают по-разному и на разных версиях тоже. Rdb$relations - не единственная системная таблица, за которой надо следить. И b/r не переживают, по-моему, все - структура ODS создаётся, а не ресторится. Закладываться даже не на недокументированные фичи, а на явные баги - путь граблей типа hardcore XXX.
упоминается IB - это требование заказчика? Заказчик готов платить за IB 6.5/7.x/2007, или он идиот, который требует использования IB 6.0?
В любом случае, используйте dbcomparer. он позволяет сравнить структуры БД и создать скрипт изменений метаданных. вешать триггеры на системные таблицы - это гуано в чистом виде.
В любом случае, используйте dbcomparer. он позволяет сравнить структуры БД и создать скрипт изменений метаданных. вешать триггеры на системные таблицы - это гуано в чистом виде.
Не понимаю, о какой задержке идёт речь? Судя по описываемой задаче, информация об изменениях в метаданных нужна в момент запуска репликатора. Дык, он её и получит надёжным способом сравнения. Зачем заранее генерировать эту информацию заведомо ненадёжными способами? Очень велика вероятность косяков, когда плановый бэкап-рестор по каким-то причинам сбойнул, а админ срочно восстанавливая базу вручную забывает прогнать скрипт. Или просто не успевает...Nat писал(а):В смысле "соблюдения протокола InterBase" получается, что скорее правильнее, чем проще. Но тогда предполагается некоторая, скорее всего приемлемая задержка, хотя и использованием триггера есть задержка, но эти две задержки несоизмеримы. Хотя в данном вопросе, учитывая многие факторы изменения метаданных, точнее сказать условия, при которых они могут меняться, эта задержка будет приемлемой, заказчик настаивает на решение проблеммы посредством триггерной логики.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Тиражирование не интересует...
сравнение структуры конечно метод, но репликация по заявленному алгоритму может начаться с отсрочкой, а за время отсрочки все изменения во вновь созданных таблицах нужно зафиксировать, кроме того, если таблица наоборот удалена, то и записи о транзакциях в удаленной таблице должны быть удалены до начала репликации.
В таком случае сравнение структур перед процессом репликации поможет только при удалении таблиц, при добавлении будет потеряна информация изменений новых таблиц.
Мои объяснения о том, что такое решение (через триггер к RDB$relations) - мягко сказать не корректно и вообще для чего этот ... нужен вызывают неоднозначную реакцию заказчика, который считает себя умнее, правда как оказалось ничего не слышал о двухфазном подтверждении. Однако настаивает, если что-то получается, пусть даже через ж..у, пусть будет. У нас с ним разногласия по вопросам первичности скорости, качества и надежности, но хозяин в данном случае барин, работать с этим ему, мы с ним никак не прикасаемся по остальным жизненным вопросам.
Это по поводу вашего удивления, к чему все это... если обычно по-другому.
Что касается ситуации b/r, поскольку эта же программа будет производить b/r, то этот триггер можно снять перед b/r и установить сразу после... На этот счет придется еще подумать и поэкспериментировать. У меня нет пока возможности изучить внутренний алгоритм действий IB/FB, хотелось бы конечно однозначно знать, что происходит внутри БД, надеюсь в скором будущем узнать... Пока же я на стадии новорожденного в этих вопросах...
С уважением... ко всем ко ищет и помогает искать истину.
сравнение структуры конечно метод, но репликация по заявленному алгоритму может начаться с отсрочкой, а за время отсрочки все изменения во вновь созданных таблицах нужно зафиксировать, кроме того, если таблица наоборот удалена, то и записи о транзакциях в удаленной таблице должны быть удалены до начала репликации.
В таком случае сравнение структур перед процессом репликации поможет только при удалении таблиц, при добавлении будет потеряна информация изменений новых таблиц.
Имеется ввиду, что данный вопрос,ИМХО,одинаково решается в IB/FB. Возможно не совсем удачно сказано. Вопрос решается на самом деле в FB 1.5.3упоминается IB - это требование заказчика? Заказчик готов платить за IB 6.5/7.x/2007
Мои объяснения о том, что такое решение (через триггер к 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 Спасибо за разъяснение процесса восстановления...
Я имел ввиду, как это реализовано исходным кодом? Я доверяю вашим знаниям в этих вопросах, в следствии прочтения ваших мыслей здесь, но мне все же любопытно посмотреть исходный код...
Спасибо большое за ваши мысли и подсказки, за ваше время...
С уважением.