"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).
> There are a whole class of applications where you need the higher end
> features that could not be implemented in SQLite. You either have to
> sacrifice portability or performance. If you sacrifice portability,
> you should at least get really good performance which I am not sure
> that SQLObject will allow.
I believe that it depends more on your own code than on SQLObject. If you
always work with, e.g., 50 records at a time, then it doesn't matter if your
RDBMS has 5K or 5M rows on any specific table: you'll always be handling 50 of
them. You have to have a good design for your database, including indexes,
views, functions / stored procedures, schemas / namespaces, etc.
What I do is having a mix of both: I have non-portable code creating functions
and views and rules and other specific stuff on a file, and I have my table
and indices on my model written in Python with SQLObject.
> By isolating my SQLObject code, I can look at that problem when I come
> to it without rewriting my entire application. For some applications,
> I expect to have to completely bypass SQLObject. I read somewhere that
> SQLAlchemy was thinking about writing a SQLObject wrapper. That might
> solve the problems.
My approach is:
- specific RDBMS niceties on a separate file
- table structure, indexes, etc. with SQLObject
- if I needed supporting some database without SP/Functions, I'd write
a library for this application and put a really BIG warning on its
file and on the database definition, so that if one is changed the
other should also be changed as well
I don't need supporting sqlite... Not on my entire application (it is used to
exchange data when client/server communication ceases, so that the client
doesn't stop processing requests).
--
Jorge Godoy <[EMAIL PROTECTED]>
