I guess and I may be wrong that the main reason for not allowing DDL operation in a trigger is due to the fact that a DDL operation will get implicitly committed, and as a trigger is always called in the context of a transaction, it cannot allow an implicit (in this case) commit of a DDL statement, neither an explicit commit...
Yes. I agree with the importance of the footprint. I don't know if DDL in Triggers would be too hard/big/convenient to implement, but the Derby Team must have their reasons.Anyway, it looks like I'll have to call the procedure directly in the application that I'm designing... that doesn't look so hard...Thanks for your replies.Javier
On 8/20/07, firstname.lastname@example.org < email@example.com> wrote:
Just a comment…
Just because another database can do something doesn't mean that it's necessarily a good idea.
The other issue with Derby is that until someone determines a way to create a "plug n play" architecture of features, it becomes more important to decide if Derby is going to be a "full fledged" database, or a lightweight embedded database.
As you increase the size of the footprint, you make it harder to embed. And as you add features, you are increasing the size of the footprint.