Jorge Godoy wrote:
"Alvin Wang" <[EMAIL PROTECTED]> writes:
From what I have been reading on the SQLobject mail list, SQLObject
does not support database level referential integrity like triggers
well. It does not support stored procedures since that is not cross
platform. It is only realistic from a product like SQLObject to
support the lowest common denominator since you don't want to be
implementing Oracle features in python so SQLite can have triggers.
The main problem is with regards to stored procedures / functions, IMHO.
Triggers can be created manually. The same applies to views, i.e., you have
to create them manually.
There's one thing that bothers me and I believe it is what you were thinking
when you said triggers: validating input with rules stored in the database. I
have some routines that I use to, for example,
- give me the next day of work after N days and considering holidays /
weekends
- tell me if some document number is correct or not
I can code those in Python, but then, if I want another interface with the
database I'll have to code them again. Today I have a GUI, a CLI and now a
web interface to my application. Coding things three times or making Python
the only language supported wouldn't be nice. Having the logic inside the
database makes it possible to insert data with pure SQL (what is a plus if you
need an autonomous system that need to operate without network connectivity).
:)
an interesting discussion about this "to trigger or not to trigger"
issue was spawned based in a blog entry on David Heinemeier Hansson's
(ruby on rails...) blog:
http://www.loudthinking.com/arc/000516.html
(read also the comments)
gabor
--
Flexibility is overrated
Constraints are liberating
- David Heinemeier Hansson, Secrets behind Ruby on Rails
