Cursor objects are supposed to be isolated. As long as you allocate two different cursors you can interweave them as much as you want. This is, in fact, the entire reason to use a cursor-based API.
--Noah On Dec 12, 2008, at 2:36 AM, osimons wrote: > > Hi all, > > I recently became aware of an issue with a script that I think > highlights a potential problem that may be a cause of some strange > issues we've seen over the years - especially with pysqlite. > > http://trac-hacks.org/ticket/2927 > > The script or the plugin is not of interest in itself, but more the > general pattern of yield'ing items from an open cursor for use by > others - and where the other use is updating the database. As I read > the code, both cursors will be created from the same connection as > they will generally be executed in the same thread. > > In Trac code (and various plugins) this kind of usage is wide-spread - > especially in the various model classes. My hunch is that it may lead > to unpredictable results if the generator is not fully consumed before > use - unpredictable as it will likely depend on how the low-level > cursor/connection code is written. If the amount of data is small, the > cursor may prefetch and cache results for use and therefore won't need > to make new roundtrips over the connection that is then currently > inside an open transaction. From the testing on that ticket, it seems > Postgres works fine but SQLite fails. > > Does anyone have deeper insights into such low-level database > behavior? Is this cause for concern? Should we rewrite our code to > consume cursors in full and return lists? Our would it be enough to > document this properly, and suggest that all usage consume the > generator before using result to update data? > > Insight most welcome... :-) > > > :::simon > > https://www.coderesort.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
