On Sep 20, 2010, at 3:51 PM, Randall Nortman wrote:
> On Sep 19, 1:52 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> On Sep 19, 2010, at 9:54 AM, Randall Nortman wrote:
> [...]
>> I think this is a bug in Pysqlite2. I can reproduce it with sqlite3
>> directly.
> [...]
>>> (I don't see where the spec says
>>> that a DBAPI connection is always in a transaction.)
>>
>> Well, that you can't/shouldn't call "BEGIN" is implied by this paragraph,
>> though weakly, but isn't specific about isolation. I also bet if you
>> emailed the DB-SIG list, they'd be interested in this detail.
>
> The DB-SIG list agrees with you:
>
> http://mail.python.org/pipermail/db-sig/2010-September/005645.html
>
> And I have filed a bug on pysqlite:
>
> http://code.google.com/p/pysqlite/issues/detail?id=21
>
> I fully expect the pysqlite folks to say "but if we fix this it will
> break existing apps which assume they can SELECT all day without
> creating transactions", particularly since pysqlite is part of the
> python standard library. The current behavior (no transactions begun
> for SELECT) is documented, so many apps may depend on it. But I agree
> with you now that it's not SQLA's problem.
They're going to say that SQLite locks the whole database file aggressively,
which is why they dont start the trans until DML. That is fine, but there
should be some option to control it. Where is the current behavior documented
? I couldn't find a link for that.
Marc Lemburg seemed to be non-specific in his comments about when the
transaction begins for isolation purposes - he just reiterated that its not
transaction-per-statement.
>
> [...]
>> Well we like that people are familiar with DBAPI and that it has no begin(),
>> so with that knowledge it should be clear that SQLA's log message of "BEGIN"
>> only represents when SQLA first starts using a DBAPI connection that has no
>> existing transactional state, and that the DBAPI is expected to have done
>> what it needs to ensure that a BEGIN has occurred. The "BEGIN" message
>> can say something like "BEGIN (implicit)" or "BEGIN (virtual)", "BEGIN
>> (assumed that the DBAPI is doing this!)" but you can be sure most people
>> aren't going to know what the heck that means and you'll just have more
>> people complaining.
>>
>
> I dunno... perhaps just don't echo BEGIN at all, since it is implicit
> and anybody who knows how DB-API is supposed to work will know that a
> transaction is beginning? Perhaps instead of echoing the SQL that's
> assumed to be executed, echo the DB-API calls that are being made. So
> messages would start to look like 'execute("SELECT ...")', 'commit()',
> 'rollback()', etc. If there were a way to get the driver to echo what
> it's actually sending to the DB, that would be great, but that's not
> part of the DB-API spec.
I really prefer it say something so I know when the connection is starting to
be worked with, and I'd prefer its not just "well turn on connection pool
logging". I've always thought BEGIN was clearest but I'm not going to fight
hard on that, so just suggest something it could say.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
