RE: [SQLObject] proxy attributes

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

>I think you may have an issue here. What benefits are you getting from
>SQLObject if you don't model those 'private' tables? I have similar
database
>setups (presenting multiple tables as unified objects), and model the
entire
>implementation. When you say you don't want to create objects for all
tables,
>I'm thinking you don't want your implementation-specific objects to be part
of
>your public interface, but I don't think you're going to get the ease of
>implementing these proxies in SQLObject without having private objects for
>every relevant table.

I should clarify- I, as the app do not care about the lesser tables. I, as
the
programmer want to do as little typing as possible to accomplish the task.
The
schema is the map and all the necessary information is in there to build the

classes automatically. When I define my classes, I would like to be able to
say
Here are my object names, here are my root tables, go build it. If I could
get
by with only defining my public(app-facing)classes and letting SO build
whatever
private(internal) classes it needs, I would be ecstatic, but that's likely
hoping
for too much.

In my specific case, there is a lot of structure in the database schema that
I
would rather not repeat by manual transcription into my classes. The scope
of
SO also includes less-featureful backends and the requirement of handling
legacy data stores in various degrees of normalization. If it can be derived
automatically, that saves me the burden of code synchronization and reduces
the 
chance of errors. If no exploitable schema exists, we can fall back to
asking
for specifications.