Re: [SQLObject] two postgres questions

[Edmund L. <el...@in...>]

Bud P.Bruegger wrote:

> thanks for your insight.  I'm still digesting but it seems that there
> is a considerable range of needs.  People (like you) who need a single
> DB model accessed by multiple languages and apps and people who do
> just python and single app (like possibly me at the moment) and don't
> do legacy db models...

Actually, I don't consider my db models to be legacy models... "legacy" 
kind of implies "out of date", "mainframe", etc.

In reality however, they are just data models that exploit the strengths 
of the relational model--data integrity, flexibility, etc.

But your observation (and Luke's) does raise a thought... perhaps there 
are three broad classes of database user:

1. Someone who wants an object store and isn't especially concerned 
about data integrity, flexibility, etc.

2. Someone who wants an object store but does want some measure of data 
integrity, has simple data models, and wants some ability to access the 
data via third party apps/tools.

3. Some who wants flexibility, ability to access the data via third 
party apps/tools, is concerned about data integrity, etc. Is willing 
trade pure object orientation for these.

It seems to me that (1) is best served by ZODB, (2) is where the ORMs 
and SQLObject are, and (3) is where people like me are, but would prefer 
not to be.


> I see three ways of doing constraint kind of stuff:
> 
> * all in python, dbms doesn't know about constraints.  This works
>   if everything that accesses the data goes through the same
>   middleware layer  (not directly to dbms)
> 
> * specification of constraints in python/middleware that translates it
>   to SQL statements to send to the dbms (such as check constraints).
>   As you already say, there is a lot of diversity with dbms
>   capabilities here  (I've only looked at Postgres so far)
> 
> * doing everything in the dbms.  
> 
> It seems that the first and last are easy, the middle one more
> difficult (as you mention).

This is what I've been forced to do. I have a thin API that the upper 
layers use to access the DB. Maybe 97% of the constraints are in the DB, 
and the remaining 3% are outside it because it was easier to debug this 
code as external Python code than horrid PL/PgSql. Isolating all the SQL 
in this layer also makes it easier to port to a different DB if I need to.


> What about a middleware layer who usually does the first solution but
> doesn't block you from doing the third?  Would that be useful or does
> anyone see a strong need for the middle solution?

I would have loved to have used SQLObject or some other alternative. I 
looked at MiddleKit, dbObj, etc. But, none of these tools made it easy 
to do complex data models.

...Edmund.