On 9/8/2012 1:21 PM, Dirk Stöcker wrote:
On Sat, 8 Sep 2012, Dirk Stöcker wrote:
Could someone please cleanup
http://trac.edgewall.org/wiki/TracDev/DatabaseApi
Actually I don't know what is right and what not. It seems I
understand the with form, but do I need a db.commit() at the end or
does the with do this automatically?
Beside this that page states the now deprecated @with... form as state
of the art.
Reading the page again and again I actually see you tried to tell old
and new forms. Better would be to state newest recommended form first.
Then after that describe how it was before and also how old forms can be
converted into new forms.
Yes, after your first mail I was in the process of clarifying it, but
feel free to integrate your examples below as well.
Actually as it is a wiki I could do some changes myself, but I don't
dare to touch that as there is too much stuff I don't really understand.
I wanted to change the code I maintained already for 0.12, but as I did
not understand the descriptions, I didn't do. As you now plan to drop
old syntax I must do, so please make the description what to do
understandabble also for someone who does not want to understand the
whole database concept, but only wants to use a database for read and
write access to store/load data.
After trying to understand that code a bit more - Is following correct:
Old code:
- db = self.env.get_db_cnx()
- cursor = db.cursor()
- cursor.execute("DELETE FROM spamfilter_bayes")
- db.commit()
Now it depends what you mean by "new".
The 0.12.x style is only supported starting with 0.12 and 1.0.x style is
only supported by 1.0, so if you have a plugin which attempts to support
both, you should therefore use the 0.12 style, with the decorators.
New code:
+ env.db_transaction("DELETE FROM spamfilter_bayes")
Yes, but this is the 1.0 style.
or:
+ with env.db_transaction as db:
+ db("DELETE FROM spamfilter_bayes")
+ db.commit()
Alternative form of the 1.0 style and, no, you shouldn't call
db.commit() yourself.
So in the above, omit the last line, as that's the whole point of nested
transaction: if that code happens to be executed as the outermost
transaction, the commit will be performed automatically upon "exit". But
if you happen to be called by some other function which has itself
started a transaction, you won't suddenly force a commit() right in the
middle of that outer transaction!
The 0.12 style would have been:
@with_transaction(env)
def clear_bayes_table(db)
cursor = db.cursor()
cursor.execute("DELETE FROM spamfilter_bayes")
quite more verbose, but that's the best with came with having the
constraint of Python 2.4 compatibility.
or:
+ with env.db_transaction as db:
+ cursor = db.cursor()
+ cursor.execute("DELETE FROM spamfilter_bayes")
+ db.commit()
Same remarks about 1.0 and commit().
And yes, you can still get a cursor if your prefer, in particular if you
don't want the implicit fetchall() to happen. But as there are good
reasons for that (locking issues with SQLite became very very rare after
that), it's better to use db.execute().
Do all these the same and first is preferred?
In this case, the first form is the preferred form, yes, if you're
targeting the 1.0 API.
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" 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/trac-dev?hl=en.
