Re: [SQLObject] a third way of accessing attributes

[Nick <ni...@dd...>]

On Thu, 2003-05-15 at 10:46, Bud P.Bruegger wrote:
> 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..

I do like that model, however you probably don't even need to make
properties and such, since it is all internally called and used by other
classes and probably never by the API user.  At least it would certainly
reduce the complexity that metaclasses bring to the game.  And by doing
that in __init__ you're not really doing much all that different from
metaclassing of the Python 1.5 days.  If you're storing mappings, just
refer to the mappings when you do an operation instead of making
yourself a bunch of lambdas.  Depending on how many operations you're
doing and how many classes you're defining, you may save yourself a lot
of up-front work and memory just to import the classes.

Nick