On Thursday 14 March 2002 08:25 am, Magnus Lie Hetland wrote:
> I've had a look at MiddleKit (which looks fine) and the
> WebKit/PostgreSQL examples from Ogg Vorbis (plain and simple, but
> with a bit much code duplication), and I'm left with the desire to
> create a generic wrapper at the level used in the Vorbis code, but
> with the generality of MiddleKit (to avoid duplication).
>
> It struck me that it probably ought to be possible to create a simple
> class to handle this sort of mapping without any csv files or
> code generation etc. It probably wouldn't be as complete, but it
> would simply need three things:
>
> 1. A table name (stored internally)
>
> 2. A load method
>
> 3. A store method
>
> It could use __setattr__ and __getattr__ to keep the explicitly set
> attributes (as opposed to methods etc) in a separate dictionary used
> when storing etc. And the Python DB API has enough introspective
> capabilities that no mapping needs to be explicitly specified.
>
> Does this sound doable (and, if that, useful)?
There are some other packages out there that are higher level than DB
API, but still lower level than MiddleKit. Can't remember the names,
since I use MiddleKit all the time, but before you crank this out, you
should search the db-sig mailing list and the Vaults.
But regarding your approach, how will you account for attributes that
should NOT be stored. It sounded like your setattr/getattr approach was
going to do everything. My experience with any archiving solution is
that there are often a few auxilliary attributes that I don't want to
archive in some of the objects. I suppose you could make use of
getstate/setstate like the pickle module does.
Also, you mentioned that no mapping needs to be explicitly specified.
However:
sql database
table Department
code char(10)
name char(100)
table Employee
dept char(10)
name char(100)
salary float
How would your mapper know that employee.dept should return a
Department object, not a 10 character string? Prehaps this is something
that "foreign keys" in Postgres could help indicate. I'm not that
familar with them.
Other ORMs that support existing databases still end up providing for
explicit configuration in order to handle object references, lists,
implicit joins for those things and other things.
-Chuck
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
