On Sat, Jun 23, 2012 at 1:54 PM, Anthony <abasta...@gmail.com> wrote: >> > You're forgetting another "layer". DAL leverages on DBAPI >> > implementation of sql drivers. >> >> Well, that's not exactly good news for transparency and ease of >> documentation. > > DB API is just a specification for Python database drivers to follow to > ensure some degree of similarity and > portability: http://www.python.org/dev/peps/pep-0249/. On net, this is > probably good news for transparency and ease of documentation because you > have some consistency across drivers. What alternative would you propose for > greater transparency and ease of documentation?
Well, earlier it was claimed that the DAL for SQLite left autocommit on, but the DBAPI says: "Note that if the database supports an auto-commit feature, this must be initially off." So now I have an extra place to go look and try to figure out, does the DAL actually implement DBAPI with autocommit or does the DAL implement DBAPI but with an exception re: autocommit? Having more places to look is not 'ease of documentation' from a user's perspective. :-/ > Again, what specific assumptions about the "intermediate glue layers" would > affect the code you would write in this case? If the issue is > auto-committing, I believe the recommended code would work in either case. > I'm not saying I would mind seeing a little more documentation regarding the > differences across some of the databases and their drivers -- I'm just > wondering how much it matters in this particular case. It matters if the query at the top of the loop holds a lock on the DB, which means that when there are no rows found to process, the database remains locked while the server is sleeping... -=Doug --
