> On Jun 16, 11:00 am, "C. Titus Brown" <c...@msu.edu> wrote:
>>
>> I'm not entirely sure I agree about adding this kind of information
>> to
>> the docs. Perhaps I'm missing something, but this seems more like a
>> programming error than a pygr error! Modifying the object you're
>> looping over is never safe in Python unless it explicitly says it is,
>> and since pygr is wrapping other Python objects, the behavior
>> depends on
>> the behavior of the wrapped objects. While this may be confusing, I
>> don't think a specific warning is needed unless there's more to this
>> than I realize.
Hi Titus,
This is a bit of a gray area, because it's a side effect of SQLTable
using a single database cursor. Kenny's code is not actually
modifying the object he's looping over, but querying it within the
loop, sort of like this:
for x in db.itervalues():
y = m[x.someID] # m in turn calls db[x.someID]...
All method calls on db share the same cursor, so the query
db[x.someID] will interfere with the ongoing db.itervalues()
iteration. This is a weakness inherent to an object-relational model
that hides detailed mechanics (like the cursor) behind an object
interface.
It occurs to me that SQLTable could protect its iterator methods
against this problem by using a new cursor allocated just for that
iterator (and then released when the iterator exits). That seems like
a very easy solution. Already in 0.8 we added a serverInfo argument
to SQLTable that would allow it create new cursors as needed. I guess
we would deprecate the old mechanism (constructing SQLTable with a
single cursor argument) in 0.8, and remove that mechanism entirely in
some future version.
I think we have a choice:
- we either need to document the side effects of cursor re-use in
SQLTable
- or we need to get rid of these side effects as I suggested above.
What do you think?
-- Chris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pygr-dev" group.
To post to this group, send email to pygr-dev@googlegroups.com
To unsubscribe from this group, send email to
pygr-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pygr-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
