El martes, 25 de septiembre de 2012 20:57:54 UTC-3, Russell Keith-Magee
escribió:
>
> On Tue, Sep 25, 2012 at 11:24 PM, maxi <[email protected] <javascript:>>
> 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?
>
No, I mean if I do select * from TABLE and inmediately I try to drop the
table whitout make a commit, the table object is still in use and then I
gen an "Object in use" exception.
Then, I need todo
- select * from TABLE <- fetch
- commit work
- drop TABLE
And the current implementation is:
cursor.execute('CREATE TABLE ROLLBACK_TEST (X INT)')
self.connection._commit()
cursor.execute('INSERT INTO ROLLBACK_TEST (X) VALUES (8)')
self.connection._rollback()
cursor.execute('SELECT COUNT(X) FROM ROLLBACK_TEST')
count, = cursor.fetchone()
# Commit is needed here
cursor.execute('DROP TABLE ROLLBACK_TEST')
self.connection._commit()
BTW, I was talking about it with the fdb main developer and he notes what
there is a possible bug here about how Transaction must work.
So, if support_transaction is the natural feature from my db engine I can
just return True. Is Ok?
Best regards.
---
Maxi
--
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/-/H88VFE55n-YJ.
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.
