On Tue, Sep 25, 2012 at 11:24 AM, maxi <maxiroba...@gmail.com> 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? Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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.
