Hi, >> I don't agree. It doesn't make sense to create one trigger object for >> DELETE, one trigger object for INSERT, and one trigger object for >> UPDATE. > Why? What are you worried about?
I'm not worried. It's just that it doesn't make sense to create multiple objects. I expect one trigger object, not multiple. This is how the fulltext index works for example. > MattShaw writes "We have logic in our triggers that uses this information > to determine what to do". My interpretation is that he'd like to know the > operation type in fire() in order to determine what to do. This doesn't require one trigger object per action. >> That's possible, also for compatibility with HSQLDB. I guess it >> doesn't make sense to change the existing interface (backwards >> compatibility); instead, an Adapter style extension could be added. > > Can you give an example of what you had in mind? See the HSQLDB documentation. > You've outlined a way for detecting whether fire() is handling UPDATE, > DELETE or INSERT. What about SELECT or ROLLBACK? Currently, there is no way to find out if a trigger was called because a transaction was rolled back, that's true. Regards, Thomas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
