On Thu, 2002-04-04 at 01:27, Edmund Lian wrote:
> Ian wrote:
>
> >>I wanted something that wrapped a normal database, not a database that
> wrapped normal Python objects.<<
>
> This is what I'm looking for too. I'm getting postings out of sequence,
> missing posts, etc. so I'm just guessing that Stephen was looking at some
> code you sent him?
Yes, it is all out of order. I posted some rough files to the list a
couple days ago.
> I'm screwing around with the problem of a minimal OR mapper right now too.
> I've taken a very close look at dbObj, PyDO, dTuple, SQLDict, MiddleKit,
> etc. and none of them seem to satisfy a few basic needs, apart from the one
> you mentioned. What I need is:
>
> 1. Something that works with multiple pools of database connections, each
> pool potentially coming from a completely different source (Oracle,
> PostgreSQL, etc.)
My program doesn't really pay attention to pooling... maybe you are
approaching it from a different direction. My objects just execute SQL
statements when they need to, and from one statement to the next they
might receive a different connection and it wouldn't matter...
> 2. Support for transactions
I didn't do this, but it would be nice... what kind of interface do you
use for this? In a multi-threaded environment, I'd be unsure about how
to lump together transactions... unless, I suppose, you have a
connection object associated with each thread's accesses.
> 3. Can wrap existing schema (allow the full richness of joins, etc.)
I started with the thinest of wrappers and have filled it out some as I
feel inspired... I haven't felt inspired enough to do joins, but I'm
getting closer. I'd want to do a lot of caching, but keeping the cache
valid is a significant problem. The many-to-many joins, or other
non-obvious joins, are a bit more difficult to properly abstract... but
then those joins maybe should be left up to the implementor.
> 4. Can be bypassed if needed
>
> 5. Can support a central query dispatch mechanism (so that the overlying
> code doesn't have to know about special syntax, schema, etc. of the
> underlying RDBMS). A query is silently translated into a native
> representation, probably using memoized lookup tables.
Have you looked at the query-generation wrapper I wrote? I'm not
entirely sure how successful the idea was, but it could create queries
from Python expressions. You had to use & and | instead of "and" and
"or", since and/or can't be overloaded, but it was otherwise fairly
similar to regular Python expressions -- unfortunately, & and | don't
have the right order of precedence.
> So far, I've got 1, 2, 4, and 5 going, but I'm still trying to find a
> decent way to (lightly) "objectify" the RDBMS. By this, I mean make it less
> onerous to manipulate in Python.
>
> My last experiment to day was to throw together some code to make tables
> become objects that understood update, select, insert, etc. messages. E.g.:
>
> # Make table accessor object for table user_table, using connection pool
> 'oracle'
> x = DBTable('user_table', 'oracle')
>
> # Return all columns, all rows
> x.select()
Is each row a distinct object, with accessors and all? How do you add
extra methods to these objects?
> # Return just col_one and col_two of a certain subset:
> x.columnList = ['col_one', 'col_two']
> x.select(where="id=1 and name='apple'")
Is x like a connection, and columnList effects the next .select
statement? That seems rather unfunctional -- why not just put it in the
select method call?
Ian
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
