Re: [SQLObject] SQLObject Events

[David W. <da...@su...>]

Luke,

> 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.

H'mm, yes that is one aspect of a tool like SQLObject, but there are 
others such as ease of updating application to revised database structure.

A lot depends on the problem domain. In a corporate environment the 
database is often used by multiple applications and has a longer life 
than individual applications. Therefore logic in the database is cheaper.

Anyway, if you dbms does not have triggers choose a proper dbms ;-)

> 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.

I would agree. Generic places to put code for for validation, 
calculation, integrrity checks, security checks, cross db updates, 
mailing updates, replication, auditing etc are all essential.

Maybe one day there could even be a deployment option to choose which 
SQLObject code runs in the client and which in the dbms as triggers ;-)

Dave
-- 
David Warnock, Sundayta Ltd. http://www.sundayta.com
iDocSys for Document Management. VisibleResults for Fundraising.
Development and Hosting of Web Applications and Sites.