On Feb 15, 2007, at 3:46 PM, Michael Schlenker wrote:
Wesley W. Terpstra schrieb:
I intend to write a GUI application backed by SQL. Several of the
windows display status that would best be represented as a
database view. What I've been thinking about is how to update the
GUI when the view changes.
[snip]
Thus, a window simply provides the VIEW definition and insert/
update/delete callbacks. Some support code creates the view and
insert()s the current contents. Then it hooks the triggers
invoking the methods to catch future updates. On widget death, the
view and triggers are dropped.
Triggers only react on update/delete/insert operations, which are
not generally available for a arbitrary view.
Databases that implement immediate materialized views propagate the
changes from the base tables to the view. I would have expected an
update/delete/insert trigger on a view to trigger under the same
criteria as when a materialized view would be updated to reflect
changes in the base tables. I'm positive that before/after triggers
work on a materialized view in this way under Oracle.
But if you slightly change your api, to provide a view definition
and a list of tables/columns to watch you can do it, just create
the triggers on the tables not on the view and take the appropriate
action in your callbacks.
You mean to basically create the hooks manually that would've been
created for a materialized view? This is certainly possible, just
error prone. I wonder how hard it would be to automatically translate
a trigger on a view into triggers over the base tables. I was hoping
for something of this nature to relieve me of responsibility for
thinking of all the ways base tables could change the view.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
