Re: [SQLObject] two postgres questions

[Bud P. B. <bu...@si...>]

This is a great discussion from which I learn a lot about
requirements.


> I don't see anything inherent in (3) that requires you to "trade pure object
> orientation", the problem is that we're not aware of an object mapper that
> supports as much as we'd like.

I suppose the biggest difference between object and relational
philosophy is what the unit of retrieval is:  while in relational DBs
you can select just a subset of columns, usually objects with a subset
of attributes don't seem to make much sense.  

What I imagine at the moment is the possibility to write an arbitrary
SQL query (or maybe better a VIEW) and relate it to a class such that
the result set can be easily used.  I would think that using this
would be an exception but that middleware layers should make this
possible. 

> 
> ...
> >  But, none of these tools made it easy to do complex data models.
> 
> Since I'm interested in making SQLObject (or a byproduct of) able to support
> what I consider to be all of relational theory in an object-accessible way,
> I'm curious what you consider to be the too-complex parts today. So far I've
> heard multi-way joins and constraints. Let me see if I can elaborate these,
> then you do the same?

It seems I have the same need to understand better..


> 1. Multi-way joins, meaning n-way intersections. I've had to hack with
> SQLObject to handle these in a reasonable way, but conceivable.
> 
> 2. Multi-way joins, meaning join traversal. Seems to be supported, although
> not necessarily efficiently. So I assume you mean (1)?

Could you give examples here for what exactly you mean and maybe how a
nice API would look like?

> 3. Date's Contraint taxonomy: 

I don't have Date's book, but believe to understand...

>Domain/type constraints, 

In an OO approach, I suppose you would express this by a class.  The
class must be concerned that only valid instances can be created.  A
python class is definitely the prefered way for me to express this.  

I see that SQL offers some constraints (Check, foreign key, unique,
etc) that can express a subset of consistency requirements.  When it
gets more complex, one needs a real programming language to express
the requirements.  While in DBMS you can do this with triggers and
stored procedures, it really becomes complex, brings portability
problems, etc.

So maybe a middleware layer should support a declarative spec of
constraints that can automatically be propagated to the dbms and also
used from python (since you may want to know about consistency also
for objects that don't go in the db...).  

But I don't see that it is easy to add consistency checks that go into
the programming domain beyond what you can do declaratively with a
pre-defined set of constraints.

> column constraints,
> table constraints, 

I thought I understand the differences in your taxonomy--but I'm
getting foggy again.  In my thinking, either an attribute or an
instance is of a certain type(/domain) and its constraints accordingly
refer either to a column or a table.  But aren't these really type
constaints in different incarnations?

> and multi-table constraints (database constraints). I'll
> probably expand on these wrt SQLObject soon, but wanted to put them all up
> here for now.

Here I have the same kind of intuition.  Wouldn't this mean that I
create a higher-level object that contains multiple lower-level ones,
each of which is physically represented in a table...


> 4. Transition constraints (column, table, multi-table) are somewhat different,
> and will almost certainly be messier. :)

What are these?

cheers
--b