[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
>>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
> - 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.
>* 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.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the DB-SIG