On Tue, Sep 25, 2012 at 11:24 PM, maxi <[email protected]> wrote: > > > El martes, 25 de septiembre de 2012 09:05:47 UTC-3, Karen Tracey escribió: >> >> On Mon, Sep 24, 2012 at 10:15 PM, maxi <[email protected]> wrote: >>> >>> Hi, >>> >>> DatabseFeatures class has a supports_transactions property for test if >>> the db engine support transactions. >>> supports_transactions implementation makes some metadata alters to check >>> this behaivor. >>> >>> Now, is really needed to do this to check transaction support? >>> I don't know exactly how many times this supports_transactions is called >>> but I think what it produce unnecessary alterations in database structure, >>> or I'm misinterpreting how it supposed works. >>> >> > > Hi Karen, > >> >> 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 ?
As I recall, the reason we can't just use a property is MySQL. There's no reliable way to tell whether the database has been set up as InnoDB, which supports transactions, or MyISAM, which doesn't. An experimental approach allows us to be certain. > BTW, What do you mean with "commit/rollback/etc are simply no-ops" ? Exactly that. On databases that don't support transactions, commit/rollback etc 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. Are you saying that the current 'supports_transaction' test is leaving data in an uncommitted state? From a quick eyeball, I don't see how -- which bit is tripping up Firebird? Where do you need to add a commit? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en.
