RE: [SQLObject] proxy attributes

[<jws...@ra...>]

>least, if you never want a distinct object representation of one table 
>vs. the other.  Though in that case, the utility of the separate tables 
>is questionable -- is it really one-to-zero-or-one?  Well, then the 

I don't really care about the extra tables. They will initalized once at 
install-time and from then on the app will be handling only the top level
objects. The app will think the email address is a property of the 
customer account, but it is really stored as a attribute of the buyer, 
which is a foreign key from the customer account. I want to present an 
simple object interface on one side and a correct relational storage
on the other side. Creating that interface is rather tedious. The 
ability of SQLObject to reverse engineer the schema is rather compelling
and would factor out huge amounts of finger-grinding code. The value 
proposition is to bury all the complexity inside the SO classes. If I
compromise the relational schema to impedance-match the application, I'll
paint myself into a functionality corner eventually. 
 
>And since you are using Postgres, views are another possibility.  I 
>don't much care for them, but they seem like a good fit to what you're 
>doing.

Possibly, but this could fit into SO, and then could be usable on various 
back-ends. Are writeable views available on all modern versions of Postgres?