Re: [SQLObject] a third way of accessing attributes

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

On 15 May 2003 10:23:14 -0500
Nick <ni...@dd...> wrote:

> On Thu, 2003-05-15 at 10:19, Nick wrote:
> > On Thu, 2003-05-15 at 07:38, Bud P.Bruegger wrote:
> > > Some time ago, Nick and Ian (and others?) discussed about two ways of
> > > exposing SQL data through object attributes:
> > > 
> > > * metaclasses (current SQLObject) that set properties
> > > * __getattr__ and __setattr__
> > > 
> > > There seems to be a third way:
> > > 
> > > * Adding methods and properties (attributes) to a class at runtime 
> > >   (sans metaclasses).  
> > 
> > The problem with this approach is that you won't be able to
> > automatically resolve foreign keys at access time unless the method for
> > accessing foreign keys is only handled through methods, which both
> > __getattr__ and properties do.
> 
> Sorry, I forgot to say what my point was :)  My point is that it's more
> convenient to treat objects as persistent using that kind of model than
> have set() and get() functions a la C (java, etc.).  You're doing nearly
> the exact same thing as properties, so why not use them.

Hi Nick,

I think there must be a misunderstanding.  I _DO_ use properties, just
that I set them at runtime  (in backend.__init__) instead of from a
metaclass.  So for all that I'm concerned, I don't see a difference to
how the property behaves  (No matter at what point of time you added
it to the class, it is there...).

Maybe some more concrete example helps:

Assume I have application classes Person and Role.  My Backend
instance contains a Mapping instance contains ClassMaps for both 
Person and Role, as well as a Many2Many Relationship between Person
and Role.  

The Person and Role role classes don't know anything about
storage--they are written as if there was no persistence at all.

Now I create my Backend instance that runs its __init__.  For each
ClassMap in its Mapping instance (i.e., ['Person', 'Role']), it does
something along the following lines:

* add a class attribute called "backendInstance" that is the python
  object reference of the backend.  This is necessary to make sure
  application objects know who to talk to in order to get their
  persistence needs satisfied.   (this is where I am at the moment)

* add methods for controlling persistence.  I'm currently thinking of 
  - insert  (new in database)
  - update  (update values in database)
  - synch   (update valued from database)
  - del
  - as well as functions to control transactions.  I was thinking of
    wrapping the record-oriented methods of the DB-API with
    object-oriented ones...  Gotta think about that one...

* add properties to traverse relationships.  There seem to be two
  options here: lazy or automatic.  This can be controlled by the
  Relationship object in the Mapping.  I haven't looked into this
  much and probably I can rip off some of SQLObject's code here..

So in summary, the touch and feel (for application programmer) should
be very similar to SQLObject except that the application class does
not subclass any persistence related class and that mappings are
defined externally to the app class much rather than inside..

later
--b


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------