Re: [SQLObject] two postgres questions

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

Bud P.Bruegger wrote:

Apologies for taking so long to reply. As I mentioned in another 
message, I've got a lot of things happening at home and work right now.

> I agree that "legacy" isn't a good term.  What I meant is really a
> pre-existing data schema that has to be accesses (in contrast to one
> that is newly created following the needs of the middleware).

I was just being sensitive... :-)  Ian's right--legacy is loaded with 
unnecessarily negative connotations in the tech industry.


> Do you see a strong need to live without such an OID?  Is it possible
> to retrofit pre-existing schemas with such an OID field?

I'm going to try (see the message I just emailed to Luke). To be honest, 
I'd rather see synthetic primary keys banished. But, while PostgreSQL 
allows changes in primary keys to cascade automatically to foreign keys 
in other tables, Oracle and a few other databases do not. So, the need 
to be portable might well necessitate synthetic keys.

I suppose that as long as one could still add integrity constraints to 
the real but non-functional primary keys, then the use of synthetic keys 
won't be so bad.


> Is this what you need or is there more to it?

Not sure yet. Since I'm in danger of being too theoretical, I'm going to 
try using SQLObject for a project, and will report where it comes up short.


> I would believe that a concrete example would be the best way of
> understanding each other.  I admit to have difficulties to fully
> understand the situation so far.  I tried to make it more concrete
> above what I have understood about constraints.  I still have only a
> vague understanding of the multiple joins...

I'll write more as I find the problems... I'll use SQLObject from the 
viewpoint of traditional data modeler--full constraints, relational 
integrity, etc. and see where I run aground...

...Edmund.