[SQLObject] proxy attributes

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

Having now worked with SQLOject a bit, I have a better idea of how I intend
to use it and it's usefulness to my task. It appears that the fit is not
complete, but I think that what I want is within the scope of what SQLObject
aspires to be.

I am working on a 3-tiered application with a relational storage at the
bottom(Postgres), Business objects in the middle(SQLObject), and a
presentation layer to be determined.

The storage will be factored relentlessly, which means lots of small,
specialized tables. I would like to use SQLObject to wrap up(join) those
tables into convenient objects that can be manipulated. As an example, we
want to have a customer account object in our app. That would be stored in
the database as a number of tables-

cust_account   - main table
buyer 	   - contact name, relates to customer account
buyer_info     - contact address info, relates to buyer 
county  	   - relates to customer
shipping_rates - relates to customer

Note that from the standpoint of the cust_account object, these are all
one-to-one relations. It should be relatively simple to traverse these
relations and present the attributes of the sub-tables as attributes of the
root class. I will call these 'proxy attributes'. If x is an instance of our
cust_account class, I should be able to do 'print x.email_addr' and get the
address of the buyer back. Obviously this only works if there is one
traversal path across the tables- one-to-one relationships. Exposing those
proxy attributes as properties of the root object is in the object-oriented
spirit of 'present the interface, hide the implementation'. There would need
to be some way of handling duplicate column names. We could either mandate
unique column names or provide a way to use aliases. 

I can imagine either reverse-engineering the database at compile-time with
_fromDatabase or explicitly defining attributes and traversal paths. 

A conceptual difference is that I do not ever intend to create classes for
minor tables. There will be objects for all the major components like
employees and customers, and there will be objects like invoices that have a
master-detail structure that will be exposed from attributes like
'line_items'. I will not be joining SQLObjects directly.


Please comment.