Trac 1.0rc1 ready for testing

[Remy Blank]

Dear Trac Users,

(It's very late here, so I'll keep this short.)

You can find the packages for Trac 1.0rc1 at the usual location:

http://trac.edgewall.org/wiki/TracDownload#LatestReleaseCandidate

Many thanks to the people who helped testing 1.0beta1. If all goes well,
Trac 1.0 should be released in a week or so.

Last call for translators: many translations are still incomplete or
contain errors. If you don't have time to complete your translation, at
least make sure that it doesn't show any errors. You can check a
translation for errors with:

make check-{language code}


-- Remy, on behalf of the Trac Team

[Christian Boos]

Hello list,

As it was *really* late, we couldn't get 0.12.4rc1 done yesterday
evening... but now we're there!

On 9/1/2012 3:06 AM, Remy Blank wrote:
> You can find the packages for Trac 1.0rc1 at the usual location:
>
> http://trac.edgewall.org/wiki/TracDownload#LatestReleaseCandidate
>

Now same thing for 0.12.4rc1:

http://trac.edgewall.org/wiki/TracDownload#LatestStableRelease

> Many thanks to the people who helped testing 1.0beta1. If all goes well,
> Trac 1.0 should be released in a week or so.

0.12.4 should also be released at the same time, if all goes well during
the last week of user testing.

>
> Last call for translators: many translations are still incomplete or
> contain errors. If you don't have time to complete your translation, at
> least make sure that it doesn't show any errors. You can check a
> translation for errors with:
>
> make check-{language code}

Same plea for 0.12.4. The translations are still mostly complete on that
branch however, so please at least just make sure that `make check`
passes. Thanks again!

>
>
> -- Remy, on behalf of the Trac Team
>

-- Christian, on behalf of the Trac Team

[Christian Boos]

Hello,

Just a quick follow-up...

>> Many thanks to the people who helped testing 1.0beta1. If all goes well,
>> Trac 1.0 should be released in a week or so.
>
> 0.12.4 should also be released at the same time, if all goes well during
> the last week of user testing.

Indeed, all went well and now the packages for Trac 1.0 and 0.12.4 are
available at the usual places:

- http://trac.edgewall.org/wiki/TracDownload#LatestStableRelease
(for 1.0)

- http://trac.edgewall.org/wiki/TracDownload#PreviousStableRelease
(for 0.12.4)

Those packages are expected to be final, but confirmation would be
welcome. If everything is indeed OK, we'll make the official
announcements tomorrow.

Again, thanks to all who participated, and let the fun begin with the
next cycle of amazing new developments (1.0 already feels a bit "old" ;-) ).

-- Christian

[Dirk Stöcker]

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.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Dirk Stöcker]

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.

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()

New code:
+ env.db_transaction("DELETE FROM spamfilter_bayes")

or:
+ with env.db_transaction as db:
+ db("DELETE FROM spamfilter_bayes")
+ db.commit()

or:
+ with env.db_transaction as db:
+ cursor = db.cursor()
+ cursor.execute("DELETE FROM spamfilter_bayes")
+ db.commit()

Do all these the same and first is preferred?

[Christian Boos]

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

[RjOllos]

On Saturday, September 8, 2012 4:45:57 AM UTC-7, cboos wrote:

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.

I've found this confusing as well, but this thread has helped a lot with my understanding. The other thing I need to sort out is whether db.rollback() should ever be called within upgrade_environment. I've been hacking these statements out of plugins (1) in order to get the plugin working with Trac 1.0, and it seems to be working fine, but I'd like to understand this better.

I'd also propose that the TracDev documentation eventually be moved into the distributed package, and indexed from TracGuide. My thinking is, Trac is built to be hacked on, so put the necessary documentation right in from of users and administrators. My second motivation is that sometimes I'm developing on Trac without an internet connection, and it would be convenient to still be able to access the documentation from the development instance. 

(1) http://trac-hacks.org/changeset/11687