Re: [SQLObject] SQLObject Events

[Luke O. <lu...@me...>]

I agree with you that currently his best bet is in-database triggers. And if
you use PostgreSQL, your triggers can even be written in python.

But a large part of the draw of SQLObject is database independence. Some
databases do not support triggers, and most that do having varying levels of
support.

Instead, what if SQLObject (or an agnostic module) provided an object-level
concept of triggers? Like the idea of putting constraints on the python side,
this would both allow us to implement functionality that is missing from most
of the databases we work with, and be able to transport between database
systems. There are other areas to improve as well in becoming a completely
database-agnostic data management system, and I'd like to make it act more
relational than network-based where reasonable. But triggers is as good a
place to start as any.

Triggers and constraints are part of the same ideas, and contraints may be a
logical place to add generic triggers.

Single column constraints
Inter-column constraints
Single table constraints
Inter-table constraints

And a few others I can't think of right now. But it starts to illustrate why
simply adding insert/update/delete triggers doesn't satisfy.

Thoughts to think about, I won't make any commitments to starting to implement
these things, but maybe someone else is interested, I'll certainly carry on
discussion.

- Luke

Quoting David Warnock <da...@su...>:

> It seems to me that this type of logic is best (for performance and so
> that all database updates are audited) and simplest written as triggers
> in the database.
>
> Why not? There are several free databases that support triggers such as
> Firebird and Postgesql.