| Subject | Re: [Firebird-Architect] Database triggers |
|---|---|
| Author | Geoff Worboys |
| Post date | 2006-09-20T21:37:59Z |
Hi Jonathon,
purpose of a sort of staging-post for metadata changes plus
they carry additional attributes used, indirectly, by the
client).
So I wonder just how common this approach has become. If
there is a fairly widespread use then it may be worth some
work to help smooth the way for clients.
While I can certainly understand the preference not to allow
direct user expansion of the system tables, the ability to
plug in triggers to react to system changes seems like a very
beneficial idea.
There are things like iblogmanager that may (you'd have to
check with the author) benefit from triggers on the relation
tables to allow automatic creation and update of log triggers
when tables are created or altered. IBObjects has a number
of features that could benefit similarly; for example DML
notification via events and triggers, or the client cache of
structure information that would like to know when it has
gotten out of sync.
Side Note: The above examples (logmanager, IBO DML stuff
and some of my own work) make me wonder whether it would be
possible to have "generic" table triggers. That is; define a
single before or after trigger than fires against all DML
(insert/update/delete on all user tables). To be useful such
triggers would need ways to interrogate what table is currently
being processed and what fields it has... so I expect this
would be non-trivial. However it would mean that instead of
needing some 200 functionally identical triggers for 200 tables
you could have just one. (Just a thought.)
--
Geoff Worboys
Telesis Computing
> In my case, I do indeed use my own parallel tables (since...
> there isn't any other option), and I can understand that it
> probably wouldn't make sense to introduce a tricky feature
> into the engine considering that it would only seldom get
> used. Besides, at least that way the exact structure of the
> system tables can be counted on.
> Anyway, I guess this is a bit of a minor issue, and perhapsI also use a set of parallel tables (these serve the dual
> not worth putting a lot of work into.
purpose of a sort of staging-post for metadata changes plus
they carry additional attributes used, indirectly, by the
client).
So I wonder just how common this approach has become. If
there is a fairly widespread use then it may be worth some
work to help smooth the way for clients.
While I can certainly understand the preference not to allow
direct user expansion of the system tables, the ability to
plug in triggers to react to system changes seems like a very
beneficial idea.
There are things like iblogmanager that may (you'd have to
check with the author) benefit from triggers on the relation
tables to allow automatic creation and update of log triggers
when tables are created or altered. IBObjects has a number
of features that could benefit similarly; for example DML
notification via events and triggers, or the client cache of
structure information that would like to know when it has
gotten out of sync.
Side Note: The above examples (logmanager, IBO DML stuff
and some of my own work) make me wonder whether it would be
possible to have "generic" table triggers. That is; define a
single before or after trigger than fires against all DML
(insert/update/delete on all user tables). To be useful such
triggers would need ways to interrogate what table is currently
being processed and what fields it has... so I expect this
would be non-trivial. However it would mean that instead of
needing some 200 functionally identical triggers for 200 tables
you could have just one. (Just a thought.)
--
Geoff Worboys
Telesis Computing