[DB-SIG] Re: DB-API wrapper with db_rows

Mike C. Fletcher mcfletch at rogers.com
Sat Jan 3 16:57:03 EST 2004


Jon Franz wrote:

>>From reading this list, I discovered Kevin Jacob's db_row which I took
><<SNIP>>
>  
>
>>Does anyone know if I have duplicated someone elses effort (Not that
>>there is much effort on my part)?  I haven't yet posted my code, but if
>>you would like a copy, just email me.
>>    
>>
Similar functionality in PyTable RDBMS DBRow class (btw, yes, I know 
about the Pytables project, that's a different package, just an 
unfortunately similar name).  It's a heavy wrapper (4 dictionaries/row 
when using update/insert functionality) focused on very flexible 
operations driven by database schema descriptions (e.g. setup of 
database from schema, insert/update/refresh/delete rows, plugging in 
arbitrary classes for row/field implementations from the schema, 
etceteras).  It works on MySQL and PostgreSQL at the moment.  It doesn't 
try to change paramstyles.  There's code to read in basic schemas from 
the database(s) as well.

PyTable rows could be much lighter-weight.  I generally only need to 
actually *produce* a few thousand of them for any given web-view, so 
haven't felt the need as of yet to optimise them.  They store the 
original DB value, the wrapped/processed value (i.e. a Password object 
for a chkpass field, or an OID object for a varchar field that says 
that's the correct type), and any newly-set values.  In practice the 
code only tends to use the "most recent" value, so I could readily 
compress down to a single array of values instead of the dictionaries 
(and use arrays regardless).

It's probably safe to say that there's lots of these wrapper modules 
with very similar and overlapping functionality.  Kevin's db_row seems 
very interesting, but I need flexible update support based on property 
changes to the row objects.  Similarly, the lazyresultset module from 
PyTable probably would be useful to someone (it's not dependent on 
anything else in PyTable).

The logic in PyTable to do fairly intelligent 
insert/update/refresh/delete queries might be useful as well some day.  
But to be really useful, we'd need to have some sort of standard for the 
wrapper modules in which to plug in all these pieces so that people can 
choose which vectors/aspects are important to them when choosing how to 
compose their own wrappers.

>* shift into thinking-out-loud mode *
>As a side question - PDO currently uses
>results['foo'].value | results.fields['foo'].value
>style syntax - we could (very) easily add
>results.fields.foo.value
> - but _should_ we do it?  It would take the number of ways to
>access  a column to 3, which seems somewhat redundant, but it
>does save 4 characters per column access.  Of course, a column
>name may be unusable for this access method without mangling -
>I'm thinking of access and spaces within a column name.
>Hrm.
>Thoughts?
>* end off-topic brainstorming junk *
>  
>
I started off just providing [ key ] and .key access, eventually had to 
add .get( key ) and .setdefault( key ) , haven't found a need for 
.fields[key] yet myself... some of the internal code uses the 
equivalent, but nothing external to the package.

Enjoy all,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/






More information about the DB-SIG mailing list