Upcoming Django release, and the future
James Bennett
As we sit here in warm, sunny Dallas, meditating on how next year's
PyCon will be in cold, cloudy Chicago, we're also getting ready to
push out a new release of Django, and with that there are some things
you all need to know, and as your friendly neighborhood release
manager it's my job to tell you :)
First, the immediate future: the goal of the first part of our PyCon
sprint this year is to get Django 0.96 rolled and released. There's a
lot of cool new stuff that's landed in trunk since 0.95 (like the
testing framework and the newforms library), and we want to get it out
in an official release.
If there's a bug that's been annoying the heck out of you and you want
it fixed before the release, this would be the time to speak up about
it. We have a fairly high concentration of Django developers all in
one place with nothing to do but code, so hopefully we'll be able to
hit a lot of stuff and get a release out very quickly (we'd like to
release 0.96 in the next day or two).
After 0.96, though, there will be some major, backwards-incompatible
changes; several things, like the admin refactoring Jacob announced
last night, will require changes that just can't be
backwards-compatible, and will require a lot of activity on trunk for
a while. In that light, Django 0.96 is important not just for getting
all the cool features we've developed on trunk since 0.95, but also
for being a relatively easy upgrade for users of 0.95 and a stable
version to run with while we do a lot of work on trunk to get some
things into their "ready for 1.0" state.
It's not clear right now how long it'll be between 0.96 and the next
release. In the meantime, 0.96 will serve as a pleasant mix of
compatibility and new features; a couple of things have changed (like
the location of the admin documentation views), but on the whole it
should be an easy upgrade for anyone who's already at 0.95.
If you've got any questions about all of this, feel free to reply and
I'll do my best to answer them or delegate to someone who can. And if
you've got some free time this week and want to help us kill bugs in
the run up to 0.96, let us know and we'll be happy to show you how you
can help.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
d...@simon.net.nz
Here's a few comments based on my triage experience (whatever that's
worth):
My vote would be for spending some time on edit_inline (e.g.
http://code.djangoproject.com/wiki/FeatureGrouping#Multipleedit_inlineissues),
as this alone is causing craploads of bugs and cleaning all these out
would be great. AFAIK, Malcolm was looking into this after his rewrite
of the query code, but I don't know if he's made any progress.
I think the next major issue is the unicodisation problems - it may be
a good idea while you're all together to sit down and plan what's
going to happen (post 0.96) as I think the newforms will start
exposing problems here (See the FeatureGrouping page for a list) - is
Unicodisation going to be a 1.0 feature for a start?
Third, there are lots of translation tickets ready for checkin, which
would be nice to patch in. Django's got a good reputation for i18n/
l10n, so getting these into 0.96 would be good. This would also give
translators a chance to find and clean up any final glitches before
1.0
Finally, it may be a good time to glance over all the "Design Decision
Needed" tickets, with most of you core dev's there, it should be an
easy yes/no process for most of them.
Cheers, & have a good one guys.
-Simon G.
Chris Moffitt
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
>
Also, I'd like to see some of the decimal related tickets worked on but
this may have to wait until 1.0.
http://code.djangoproject.com/wiki/VersionOneFeatures#DecimalField
Enjoy Dallas & thanks for all the hard work!
-Chris
Malcolm Tredinnick
> Excellent, I hope you guys get many hours for coding!
>
> Here's a few comments based on my triage experience (whatever that's
> worth):
>
> My vote would be for spending some time on edit_inline (e.g.
> http://code.djangoproject.com/wiki/FeatureGrouping#Multipleedit_inlineissues),
> as this alone is causing craploads of bugs and cleaning all these out
> would be great. AFAIK, Malcolm was looking into this after his rewrite
> of the query code, but I don't know if he's made any progress.
I wasn't going to look at it unless I ran out of things to do. That
hasn't happened yet. You may remember me saying I don't like edit
inline, so developing enthusiasm to look at these bugs is difficult. We
have to fix them somehow, so if somebody else wants to do that, I'm not
going to mind at all.
Malcolm
Jacob Kaplan-Moss
> My vote would be for spending some time on edit_inline (e.g.
> http://code.djangoproject.com/wiki/FeatureGrouping#Multipleedit_inlineissues),
> as this alone is causing craploads of bugs and cleaning all these out
> would be great. AFAIK, Malcolm was looking into this after his rewrite
> of the query code, but I don't know if he's made any progress.
Edit-inline is actually getting a major, hardcore cleanup and rewrite
as part of switching to newforms in the admin. That means I'm content
to leave it semi-broken (it still works 90+% of the time) until
newforms-admin is integrated.
I think everyone will be pleased with the improved edit inline, FWIW.
> I think the next major issue is the unicodisation problems - it may be
> a good idea while you're all together to sit down and plan what's
> going to happen (post 0.96) as I think the newforms will start
> exposing problems here (See the FeatureGrouping page for a list) - is
> Unicodisation going to be a 1.0 feature for a start?
That's definitely something we need to decide, but not for 0.96. That
is, because anything we do in this regard will break old code, 0.96
should have the same (broken) behavior w.r.t unicode.
> Third, there are lots of translation tickets ready for checkin, which
> would be nice to patch in. Django's got a good reputation for i18n/
> l10n, so getting these into 0.96 would be good. This would also give
> translators a chance to find and clean up any final glitches before
> 1.0
Can someone can give me a one- or two-sentance explanation on how I
should check those in (just apply the diffs? Or do I need to rebuild
the language files, and if so how?) If so, I'll check 'em in.
> Finally, it may be a good time to glance over all the "Design Decision
> Needed" tickets, with most of you core dev's there, it should be an
> easy yes/no process for most of them.
That's one thing I'm planning on doing tomorrow.
Thanks, Simon!
Jacob
Jacob Kaplan-Moss
> Also, I'd like to see some of the decimal related tickets worked on but
> this may have to wait until 1.0.
> http://code.djangoproject.com/wiki/VersionOneFeatures#DecimalField
Did anyone ever figure out if we can (legally/morally) include
decimal.py as django.utils.decimal (for 2.3 support)?
Jacob
Malcolm Tredinnick
> On 2/25/07, si...@simon.net.nz <d...@simon.net.nz> wrote:
> > Third, there are lots of translation tickets ready for checkin, which
> > would be nice to patch in. Django's got a good reputation for i18n/
> > l10n, so getting these into 0.96 would be good. This would also give
> > translators a chance to find and clean up any final glitches before
> > 1.0
>
> Can someone can give me a one- or two-sentance explanation on how I
> should check those in (just apply the diffs? Or do I need to rebuild
> the language files, and if so how?) If so, I'll check 'em in.
Apply the patch to the correct directory under
django/conf/locales/<lang_code>/LC_MESSAGES/ .
Regenerate the .mo files, since we are storing them in subversion, too.
This requires running bin/compile-messages.py from the django/ directory
in your source tree. This should only change the .mo files for any .po
files that you just patched. It also should not generate any warnings:
if it does, they are worth fixing (or emailing about so that others can
fix them).
Then check in the 2 - 4 changed files.
If you are adding a new locale, the procedure is a little longer, but
not much worse:
(1) Add the new language to django/conf/global_settings.py
(2) Run bin/make-messages.py -l <language_code> (note that for
some locales, the language code might be of the form ll_CC,
where CC is a country or region code. E.g. fr_CA and fr_FR are
different locales, whereas we would only have a single cy
(Welsh) locale. The person supplying the locale file will
mention if it's a specific region, although sometimes experience
helps, too.
(3) The make-messages script will create the django/conf/locale
directory. Now you can add in the new django.po and/or
djangojs.po files and run compile-messages again.
All of the above is documented in docs/i18n.txt if you forget.
Also,
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Translations&order=priority shows the outstanding translation files (they should all be in the internationalisation component).
Mario Gonzalez posted to the i18n list yesterday that he was going to
update the Spanish one, including merging the two existing patches
together (#3097 and #3555), so you may want to leave those two for a day
or two.
Regards,
Malcolm
Malcolm Tredinnick
I have concerns about this solution (dropping in the decimal module),
regardless of legal status. It just feels icky. The problem is that,
even if you are using a nice modern Python, you will need to continually
import Django's version of decimal.
Although we say that Django runs on Python 2.3, do we have to say it has
all the features that later Python versions do? I mean, if you are using
Python 2.3, you are not using decimal types in any of your code (except
in a near-future version of Django).
This would be analogous to the fact that whilst all of our database
backends support the basic functionality, some of them have extra
features and some of them are lacking certain things (e.g. referential
integrity in SQLite). We could say that FloatField converts to floats in
Python 2.3 -- with the acknowledged loss of precision -- and the
built-in decimal type in 2.4 and later. That only leaves the slightly
odd name for later versions (because it's not a float field, it's a
fixed-point field).
This isn't a showstopper or anything, but if every package went down
this road, you'd end up importing 47 different decimal modules. If
people want the decimal type, upgrading to Python 2.4 or 2.5 is the
solution. Otherwise, living without is something you already know how to
do if you are using Python 2.3 (and I say this as somebody who's written
a lot of financial code in earlier Python versions, so using floats was
not an option).
Cheers,
Malcolm
Malcolm Tredinnick
> > Third, there are lots of translation tickets ready for checkin, which
> > would be nice to patch in. Django's got a good reputation for i18n/
> > l10n, so getting these into 0.96 would be good. This would also give
> > translators a chance to find and clean up any final glitches before
> > 1.0
>
> Can someone can give me a one- or two-sentance explanation on how I
> should check those in (just apply the diffs? Or do I need to rebuild
> the language files, and if so how?) If so, I'll check 'em in.
I had some time whilst dinner was cooking tonight, so I went ahead and
checked in the half-dozen translation files (with the exception of the
two Spanish ones that are going to merged).
Malcolm
Chris Moffitt
> Did anyone ever figure out if we can (legally/morally) include
> decimal.py as django.utils.decimal (for 2.3 support)?
>
Given Malcolm's perspective, let me know if the design decision would be
to include decimal.py. If it is, I can try to do some leg work to track
down the legal aspects. Just let me know.
-Chris
Chris Brand
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
I've been using 0.95 for a few months now, and the one thing that is really
annoying is using foreign keys in filter() and order_by() statements. Not
sure about a bug # (I will see if I can find one), but I always seem to end
up with errors about unknown table names, and end up having to do the
filtering or ordering in python rather than in the SQL. This is with MySQL
as the db, BTW, which I guess might make a difference.
Chris
Jacob Kaplan-Moss
> I've been using 0.95 for a few months now, and the one thing that is really
> annoying is using foreign keys in filter() and order_by() statements. Not
> sure about a bug # (I will see if I can find one), but I always seem to end
> up with errors about unknown table names, and end up having to do the
> filtering or ordering in python rather than in the SQL. This is with MySQL
> as the db, BTW, which I guess might make a difference.
Please do elaborate on this. AFAIK FKs in filter() work just fine, so
if there's something broken we should know about it right away.
Jacob
Chris Brand
> if there's something broken we should know about it right away.
I found ticket 2076, but that only concerns order_by().
I haven't got access to my code at the moment.
Chris
Tim Chase
I'm not sure how Chris is filtering/ordering, but there are
several ways of specifying fields, depending on the context. In
filtering, one needs to use the double-underscore scheme as in
Foo.objects.filter(foreignfieldname__foreignfield = 42)
whereas in ordering, IIRC, you have to use periods instead:
Entry.objects.order_by('-blogs_blog.name', 'headline')
Both work in Trunk, but their syntax is different enough that it
can sting ya if you're not expecting it. YMMV, but it works for
everything I've thrown at it.
-tim
Chris Brand
> several ways of specifying fields, depending on the context. In
> filtering, one needs to use the double-underscore scheme as in
>
> Foo.objects.filter(foreignfieldname__foreignfield = 42)
>
> whereas in ordering, IIRC, you have to use periods instead:
>
> Entry.objects.order_by('-blogs_blog.name', 'headline')
>
> Both work in Trunk, but their syntax is different enough that it
> can sting ya if you're not expecting it. YMMV, but it works for
> everything I've thrown at it.
>
Nothing helped my particular problem.
Chris
Andrew Diederich
> If you've got any questions about all of this, feel free to reply and
> I'll do my best to answer them or delegate to someone who can. And if
> you've got some free time this week and want to help us kill bugs in
> the run up to 0.96, let us know and we'll be happy to show you how you
> can help.
I'd like to see the mssql patches applied, ticket
http://code.djangoproject.com/ticket/2358. I'd also like to see the
postgresql_psycopg2 database option mentioned in the default comments
in the settings.py file for the DATABASE_ENGINE setting.
--
Best regards,
Andrew Diederich
Chris Brand
Ok, I got hold of my code.
Of course (I had a feeling that this was going to happen), the only places I
can find where I couldn't get filtering to work are where I'm doing
something that is probably too complex to do with SQL (although I'm no SQL
expert).
Here's the function I ended up with after trying to get it going with
filter() :
def exception_age(request, year_filter):
"""Lists cadets that might not be the right age for the course they
applied for."""
this_june = date(int(year_filter), 6, 1)
this_sept = date(int(year_filter), 9, 1)
apps = list(Application.objects.filter(year=year_filter))
# filter out any that are definitely the right age
apps = [a for a in apps if (a.cadet.age_on(this_june) <
float(a.camp.min_age)) or (a.cadet.ages_out() < this_sept)]
I don't have the filter() versions that I tried along the way, but it was
based on comparing the application.cadet.date_of_birth field.
This one involves comparing the values in two tables :
def exception_eligibility(request, year_filter):
"""Lists cadets not in the right level for the course they applied
for."""
apps = list(Application.objects.filter(year=year_filter))
# filter out any that are in the right level
apps = [a for a in apps if a.training_level < a.camp.min_training_level]
# Sort the list by squadron number
apps.sort(key=sqn_of_app);
return render_to_response('camps/exception_eligibility.html',
{'object_list' : apps,})
and this one requires doing a calculation on the difference between two
fields (cadet.date_of_birth and cadet.enrollment_date) :
def exception_enrollment(request, year_filter):
"""Lists cadets enrolled too young who've applied this year."""
apps = list(Application.objects.filter(year=year_filter))
# filter out any that joined old enough
cdts = [a.cadet for a in apps if a.cadet.age_at_enrollment() < 12]
# Sort the list by squadron number
cdts.sort(key=sqn_of_cdt);
return render_to_response('camps/exception_enrollment.html',
{'object_list' : cdts,})
I do have examples of where order_by doesn't work. Here's one :
def wing(app):
return app.cadet.sqn.wing.name
def camp_csv(request, year_filter, object_id):
[...]
app_list = list(camp.application_set.filter(year=year_filter))
# Sort by wing
app_list.sort(key=wing)
# app_list =
camp.application_set.filter(year=year_filter).order_by('camps_application__c
adet.sqn.wing.name')
[...]
You can see where I've commented-out what I wanted to do. The commented-out
version gives :
Exception Type: OperationalError
Exception Value: (1054, "Unknown column
'camps_application__cadet.sqn.wing.name' in 'order clause'")
This is following a series of foreign keys (application belongs to cadet,
belongs to sqn, belongs to wing).
Chris
Jacob Kaplan-Moss
> I'd like to see the mssql patches applied, ticket
> http://code.djangoproject.com/ticket/2358. I'd also like to see the
> postgresql_psycopg2 database option mentioned in the default comments
> in the settings.py file for the DATABASE_ENGINE setting.
MSSQL, unfortunately, will likely need to wait until after Malcolm
does his QuerySet refactoring (otherwise the code's just too
difficult).
For the other bit, though, see [4624].
Jacob
Jacob Kaplan-Moss
[snip]
Can you create a ticket with this on it so I don't lose track of it?
Reading through it all is a little difficult, so I'm gonna want to
have it somewhere I can refer back to.
Thanks!
Jacob
Chris Brand
http://code.djangoproject.com/ticket/3587
Chris
Tim Chase
> camp.application_set.filter(year=year_filter).order_by('camps_application__c
> adet.sqn.wing.name')
>
> version gives :
> Exception Type: OperationalError
> Exception Value: (1054, "Unknown column
> 'camps_application__cadet.sqn.wing.name' in 'order clause'")
You have an addiction to dots...if you were doing unit tests,
this would be A Good Thing(tm) :) However, in an ORDER BY
clause, not so much.
IIUC, you need to do a select_related() to attach the various
tables to the query, and then you need to refer to the actual
table that contains the "name" on which you sort. This would
most likely be something like
camp.application_set.select_related().filter(
year=year_filter).order_by('camps_wing.name')
where "camps_wing" is the name of the table that contains the
"name" field on which you want to sort. Or, perhaps it would be
"camps_application__cadet__sqn__wing.name"
or some such combo. The SQL that Django dumps in the 404 should
be enough to figure out the alias for the table that's used.
AFAIK, a SQL "ORDER BY" clause expects "tablename.fieldname" (NB:
/only/ one period)
-tkc
Tilo Kussatz
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
To me, solving the character encoding problems concerning newforms
would be most important.
http://groups.google.com/group/django-developers/browse_thread/thread/4b71be8257d42faf?hl=en
We've been using newforms so far, but might have to switch back to
oldforms if no appropriate solution surfaces... The choice between
proper encoding and forwards compatibility is a real tough one.
If a fix or an "official proposal" on how to handle this could be
found and made public, we'd be more than happy.
Thanks!
Tilo
Chris Brand
> this would be A Good Thing(tm) :) However, in an ORDER BY
> clause, not so much.
I wouldn't cause it an addiction as such. I may occasionally use them a
little more than is good for me...:-)
>
> IIUC, you need to do a select_related() to attach the various
> tables to the query, and then you need to refer to the actual
> table that contains the "name" on which you sort. This would
> most likely be something like
>
> camp.application_set.select_related().filter(
> year=year_filter).order_by('camps_wing.name')
This works. Thank you very much indeed.
Interesting. When I read the documentation about select_related() :
" This is a performance booster which results in (sometimes much) larger
queries but means later use of foreign-key relationships won't require
database queries.", I assumed that "this is a performance booster" meant
that I didn't need to worry about it until I had a performance problem, but
clearly it does change the behaviour (because taking it out of this line
returns me to "OperationalError" land).
Chris
Chris Brand
>>> from camps import models
>>> app_list =
models.Application.objects.select_related().order_by('camps_board_time_block
.start_time')
>>> app_list
Traceback (most recent call last):
File "<console>", line 1, in ?
File
"/usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/models/que
ry.py", line 97, in __repr__
return repr(self._get_data())
File
"/usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/models/que
ry.py", line 430, in _get_data
self._result_cache = list(self.iterator())
File
"/usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/models/que
ry.py", line 172, in iterator
cursor.execute("SELECT " + (self._distinct and "DISTINCT " or "") +
",".join(select) + sql, params)
File
"/usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/backends/u
til.py", line 12, in execute
return self.cursor.execute(sql, params)
File
"/usr/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django/db/backends/m
ysql/base.py", line 35, in execute
return self.cursor.execute(sql, params)
File "/usr/lib/python2.4/site-packages/MySQLdb/cursors.py", line 137, in
execute
self.errorhandler(self, exc, value)
File "/usr/lib/python2.4/site-packages/MySQLdb/connections.py", line 33,
in defaulterrorhandler
raise errorclass, errorvalue
OperationalError: (1054, "Unknown column 'camps_board_time_block.start_time'
in 'order clause'")
I've tried substituting fields of other related tables, and they work fine.
Going directly into the db, I think I have everything spelled correctly :
mysql> describe camps_board_time_block;
+------------+---------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| board_id | int(11) | NO | MUL | | |
| start_time | time | NO | | | |
| end_time | time | NO | | | |
| _order | int(11) | YES | | NULL | |
+------------+---------+------+-----+---------+----------------+
Is there a way to get at the actual SQL that's being executed ?
Chris
Andrew Diederich
That's too bad. I have the patches in #2358, at least, to keep me
going for now, which is good.
> For the other bit, though, see [4624].
This ticket doesn't exist. I looked for similarly numbered ones, but
didn't find it.
James Bennett
> On Monday, February 26, 2007, 3:00:30 PM, Jacob Kaplan-Moss wrote:
> > For the other bit, though, see [4624].
>
> This ticket doesn't exist. I looked for similarly numbered ones, but
> didn't find it.
That's changeset 4624, not ticket 4624:
http://code.djangoproject.com/changeset/4624
d...@simon.net.nz
Malcolm said:
> I wasn't going to look at it unless I ran out of things to do. That
> hasn't happened yet. You may remember me saying I don't like edit
> inline, so developing enthusiasm to look at these bugs is difficult. We
> have to fix them somehow, so if somebody else wants to do that, I'm not
> going to mind at all.
Not a problem :) and it looks like they'll all be going away anyway.
Jacob said:
>Edit-inline is actually getting a major, hardcore cleanup and rewrite
>as part of switching to newforms in the admin. That means I'm content
>to leave it semi-broken (it still works 90+% of the time) until
>newforms-admin is integrated.
>I think everyone will be pleased with the improved edit inline, FWIW.
Excellent, and I'm guessing the proposed changes to the admin settings
will
also affect this. I'll keep an eye on these tickets and check that
they're
no longer relevant once this has been done.
Everyone: I'm enjoying the rampage going on at the moment - keep up
the good work!
--Simon
Sean De La Torre
>> going for now, which is good.
Sean
Malcolm Tredinnick
[...]
> OperationalError: (1054, "Unknown column 'camps_board_time_block.start_time'
> in 'order clause'")
>
> I've tried substituting fields of other related tables, and they work fine.
>
> Going directly into the db, I think I have everything spelled correctly :
> mysql> describe camps_board_time_block;
> +------------+---------+------+-----+---------+----------------+
> | Field | Type | Null | Key | Default | Extra |
> +------------+---------+------+-----+---------+----------------+
> | id | int(11) | NO | PRI | NULL | auto_increment |
> | board_id | int(11) | NO | MUL | | |
> | start_time | time | NO | | | |
> | end_time | time | NO | | | |
> | _order | int(11) | YES | | NULL | |
> +------------+---------+------+-----+---------+----------------+
>
> Is there a way to get at the actual SQL that's being executed ?
Providing you have DEBUG=True in your settings file, you can do this. If
you import django.db.connection and then have a look inside
connection.queries, you will see the SQL that is being executed. It is a
list of dictionaries, each dictionary contains the time the query took
and the query itself. The query should be included in that list even if
it raises an exception.
Regards,
Malcolm
omat * gezgin.com
selection precedence and/or force a preset language in
get_language_from_request, as discussed here:
http://groups.google.com/group/django-users/browse_thread/thread/15ec233671b0beed
Thanks,
oMat
On 27 Şubat, 02:26, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Manoj Govindan
Also, am I the only one waiting for them? ;)
Regards,
Manoj
On Feb 26, 9:56 am, "James Bennett" <ubernost...@gmail.com> wrote:
> Upcoming Django release, and the future
>
> As we sit here in warm, sunny Dallas, meditating on how next year's
> PyCon will be in cold, cloudy Chicago, we're also getting ready to
> push out a new release of Django, and with that there are some things
> you all need to know, and as your friendly neighborhood release
> manager it's my job to tell you :)
>
> First, the immediate future: the goal of the first part of our PyCon
> sprint this year is to get Django 0.96 rolled and released. There's a
> lot of cool new stuff that's landed in trunk since 0.95 (like the
> testing framework and the newforms library), and we want to get it out
> in an official release.
>
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
>
> After 0.96, though, there will be some major, backwards-incompatible
> changes; several things, like the admin refactoring Jacob announced
> last night, will require changes that just can't be
> backwards-compatible, and will require a lot of activity on trunk for
> a while. In that light, Django 0.96 is important not just for getting
> all the cool features we've developed on trunk since 0.95, but also
> for being a relatively easy upgrade for users of 0.95 and a stable
> version to run with while we do a lot of work on trunk to get some
> things into their "ready for 1.0" state.
>
> It's not clear right now how long it'll be between 0.96 and the next
> release. In the meantime, 0.96 will serve as a pleasant mix of
> compatibility and new features; a couple of things have changed (like
> the location of the admin documentation views), but on the whole it
> should be an easy upgrade for anyone who's already at 0.95.
>
> If you've got any questions about all of this, feel free to reply and
> I'll do my best to answer them or delegate to someone who can. And if
> you've got some free time this week and want to help us kill bugs in
> the run up to 0.96, let us know and we'll be happy to show you how you
> can help.
>
David Larlet
>
> Will 0.96 have support for fixtures (a la #2333)?
> Also, am I the only one waiting for them? ;)
>
Read the entire thread, we are all waiting for a single word of Adrian ;-).
Cheers,
David Larlet
Russell Keith-Magee
FYI - that word has now been received. I'm working on merging in the
patch at the moment.
Yours,
Russ Magee %-)
Dirk Eschler
Hi James,
[...]
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
not really a bug, more an usability issue:
The available user permissions select in the user detail view of the admin
interface should include the app name.
Say you have two apps, both with a class "section". In this case it's
impossible to tell which section you assign permissions to. Both appear
as "section | Can add section" etc. in the permission select box, which can
in the worst case (if you choose the wrong one) become a security problem as
well.
Best Regards.
--
Dirk Eschler <mailto:dirk.e...@gmx.net>
http://www.krusader.org
Phil Powell
> If there's a bug that's been annoying the heck out of you and you want
> it fixed before the release, this would be the time to speak up about
> it. We have a fairly high concentration of Django developers all in
> one place with nothing to do but code, so hopefully we'll be able to
> hit a lot of stuff and get a release out very quickly (we'd like to
> release 0.96 in the next day or two).
My vote would be for a design decision to be made on 1541 and other
tickets related to mail.
-Phil
Ramiro Morales
On 2/26/07, Chris Brand <cbr...@redback.com> wrote:
>
Please apply & test the patch attached to ticket #2076 because I suspect this
is the same issue. The select_related() call you are using is a workaround to
the real problem as suggested by Malcolm and the patch intends to be a
solution to the real problem (note the notation to be used in the
order_by call changes, see the documentation).
We need the patch tested in as many real world scenarios like yours as we can.
Tell us how it did for you.
Regards,
--
Ramiro Morales
Ramiro Morales
>
> Please apply & test the patch attached to ticket #2076 because I suspect this
> is the same issue. The select_related() call you are using is a workaround to
> the real problem as suggested by Malcolm and the patch intends to be a
> solution to the real problem (note the notation to be used in the
> order_by call changes, see the documentation).
>
> We need the patch tested in as many real world scenarios like yours as we can.
> Tell us how it did for you.
>
Just to add thta the patch is not complete, there are a couple of ideal
characteristics it still is missing (read the commeents for details).
But it could be of great help in you situation and it would be great
if you help us by testing it.
Regards,
--
Ramiro Morales
Andrew Diederich
> On 2/26/07, Andrew Diederich <andre...@gmail.com> wrote:
>> On Monday, February 26, 2007, 3:00:30 PM, Jacob Kaplan-Moss wrote:
>> > For the other bit, though, see [4624].
>>
>> This ticket doesn't exist. I looked for similarly numbered ones, but
>> didn't find it.
> That's changeset 4624, not ticket 4624:
> http://code.djangoproject.com/changeset/4624
Whoops -- I knew about the #ticketnumber searching in trac, but not
the [changeset] shortcut. Thanks.
This changeset just applies to the install.txt file. Is there one
that changes the generated settings.py file? By default it's
something like:
DATABASE_ENGINE = '' # 'postgresql', 'mysql', 'sqlite3' or 'ado_mssql'.
and it'd be better if it also specified postgresql_psycopg2 as well.
I'm happy to log a ticket if that's the best way to get it recorded
and included.
Marc Fargas Esteve
There's a ticket for that openned: http://code.djangoproject.com/ticket/3589
And it's closed as fixed :)
Andrew Diederich
> Hi Andrew,
> There's a ticket for that openned:
> http://code.djangoproject.com/ticket/3589
> And it's closed as fixed :)
Thanks! The ticket itself doesn't have 'postgresql_psycopg2' in it,
so I didn't find it searching. And it was fixed since my last svn
checkout.
Chris Brand
> > Please apply & test the patch attached to ticket # 2076
>
> if you help us by testing it.
I will do so, but it's going to be a week or so before I have the time to
get to it.
I assume the documentation you mention is in the file docs/db-api.txt ?
Chris
Ramiro Morales
>
> I will do so, but it's going to be a week or so before I have the time to
> get to it.
>
> I assume the documentation you mention is in the file docs/db-api.txt ?
After you apply the patch, yes. See the .diff file to find the proposed
modifications it would introduce.
btw I've just attached ticket-2076.6.diff with fixes in the docs.
Regards,
--
Ramiro Morales
Lakin Wecker
If there's a bug that's been annoying the heck out of you and you want
it fixed before the release, this would be the time to speak up about
it. We have a fairly high concentration of Django developers all in
one place with nothing to do but code, so hopefully we'll be able to
hit a lot of stuff and get a release out very quickly (we'd like to
release 0.96 in the next day or two).
I don't know about the rest of you, but I'm whole heartedly switching to python2.5. I ran across this bug: http://code.djangoproject.com/ticket/3519 yesterday.
This has me worried that there aren't as many django users testing with python2.5 and that we may not have fleshed out all of the bugs that may be present.
It would be a shame to ship 1.0 without fully testing Django with python2.5.
Lakin