El martes, 25 de septiembre de 2012 21:01:39 UTC-3, Karen Tracey escribió:
>
> On Tue, Sep 25, 2012 at 11:24 AM, maxi <maxir...@gmail.com
> <javascript:>>wrote:
>
>> El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey
>> escribió:
>>
>>> First, this method is used during testing, generally not during normal
>>> operation. It's implemented as a cached property so regardless of how many
>>> times the value is tested the underlying code which creates and drops a
>>> table is only actually called once per database. Is it needed? We need to
>>> know if the database actually supports transactions or if
>>> commit/rollback/etc are simply no-ops. If you know of an alternative way of
>>> determining this, that works across all databases, please share. I added
>>> that code and I've never liked it but I don't know of another way to
>>> accomplish what it needs to do.
>>>
>>>
>> No, I just answer because it caught my attention. Why not just trust in a
>> True/False property ?
>> BTW, What do you mean with "commit/rollback/etc are simply no-ops" ?
>>
>>
> We have no single value we can set for this property for MySQL; whether
> that DB supports transactions is dependent on the configuration of the DB
> server. If the MySQL server is configured to use the MyISAM storage engine,
> then all transaction methods such as commit and rollback simply do nothing
> (are no-ops).
>
>
>> I'm working on django-firebird backend implementation (now using the new
>> firebird python-driver "fdb") and I need reimplement supports_transactions,
>> because I need to commit any work before drop the table, otherwise, I fall
>> into "Object in use" error.
>>
>
> That seems odd. What does "object in use" mean? The routine is currently
> coded to:
>
> 1 - create table
> 2 - commit #1
> 3 - insert row into table
> 4 - rollback #3
> 5 - select count of rows in table
> 6 - read result of #5
> 7 - drop the table
>
> You need to commit before #7? Doesn't seem like that should be necessary.
> Can you elaborate on why Firebird thinks it is necessary?
>
Yes, I need to commit before 7 because the transaction is still active in
that point.
cursor.execute('SELECT COUNT(X) FROM ROLLBACK_TEST')
count, = cursor.fetchone()
self.connection.commit() # <-- I need add this.
cursor.execute('DROP TABLE ROLLBACK_TEST')
self.connection._commit()
cursor.execute start a new transaction, but cursor.fetchone() does not
close it. Then I need a explicit commit, otherwise, drop table will fail
because the table is still in use for the current active transaction.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/TSaDbzruc6gJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
