Re: MySQL index hints
On Sun, Jul 4, 2010 at 1:10 PM, Simon Litchfield wrote:
> For those of us using MySQL, having large tables, whilst also wanting
> queryset goodness --
> http://code.djangoproject.com/ticket/11003
>
> It goes a little something like this --
> Model.objects.filter(field=value).with_hints('my_index')
>
> All those in favour say I.
Nay. :-)
Or, at least, not until you demonstrate how the same syntax is
interpreted in Postgres, SQLite, Oracle, any other SQL database, and
potentially on MongoDB, Cassandra, BigTable, or other noSQL datastore.
This was the biggest problem when I closed #11003 originally; it
remains the biggest problem. I'm not in favor of adding an ORM
extension that is only useful for MySQL's query optimizer. That
defeats the purpose of having a cross-database ORM syntax. If you are
at the point of optimizing your system and you discover that you have
a dataset and query that actually require database-specific fine
tuning, I don't see it as an unreasonable requirement that you crank
out some database-specific raw SQL.
Django's ORM isn't intended to be perfect for all situations. It's
intended to make the 80% case trivial so you can bootstrap a site
without having to worry about the little details. Once you've hit that
point and you're tuning performance, you're going to need to pay close
attention to the little details like exactly how your site uses SQL.
Attempting to find a way to express every possible SQL statement,
including backend-specific optimizations, into an ORM syntax is folly.
After all, we already have a syntax that is able to express every
possible SQL statement... it's called SQL :-)
That said -- I'm not fundamentally opposed to the idea of introducing
hinting tools to the ORM, as long as:
* they are demonstrably rich enough to get the job done,
* have an interpretation that is compatible with the cross-platform,
reusable-app message that underpins Django's design philosophy.
To that end, the 'with_hint()' proposal appeals to me a lot more than
the previous suggestion of Yet Another Extra Argument. However, the
patch as provided:
1) Doesn't contain tests or docs
2) Will break queries if the user includes the with_hint() clause on
any database other than MySQL
3) Even then, only supports the USE INDEX keyword, not FORCE INDEX or
IGNORE INDEX
4) Doesn't suggest how hinting strategies would be implemented on a
database other than MySQL
If you can come up with answers to these points, I might get
interested. 1 and 2 are fairly trivial; I can think of some obvious
answers for 3, but 4 is the big problem, and will require some serious
research and consideration.
I would also add that if this is a query extension that you really do
want, it's something that should be possible to add by writing a
custom database backend that extends Django's MySQL backend and
provides a custom Query base class -- and if this can't be done
relatively easily, then a refactoring of the sql.Query or SQLCompiler
interface to allow easier query rewriting by a backend *is* something
I could get behind very easily.
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 django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
documentation re-factor for 1.3?
There are two types of documentation, "reference" documentation (articles explaining all about one specific object such as slugify or the Feed class), and "topical" documentation (articles explaining how to do stuff like write templates). It seems right now, django's documentation is trying to do both at the same time. One project that does reference documentation really well, imo, is PHP. For example: http://us3.php.net/preg_replace Say what you will about PHP, but it's documentation for each function it provides is top notch. I really wish django had something like that for each function it provides. Yesterday I wanted to add the RegexValidator to my project, but couldn't figure out how to import it because the documentation didn't mention where the validators lives. I had to resort to googling "RegexValidator django import" and came across some random pastebin which had the import, and then went from there. That wasn't the first time I had to do this. I think what we should so is totally revamp the documentation for the 1.3 release. I'm willing to do most of the work. I shouldn't be too hard to do because right now everything is mostly already written, just not organized very well. Right now the documentation consists of a relatively small number of pages that are sometimes 50 or 60 screens long (obviously depending on screen resolution). What I think it better is to have a much larger number of pages, each only being 10 screens long max. One page for each model field, one page for each widget type, one page for each template tag, etc. Then each page can link to the corresponding "topical" documentation page to see how that function/class/object relates to the big picture. Has there been any real discussion on how to move the documentation forward? I know there has been murmurs over the years on how django's documentation is in need of some organizing... Here are some quick and dirty examples of what I'm thinking about: http://pastebin.com/Cp2FK34V http://pastebin.com/ZQQ4z9B9 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Sun, Jul 4, 2010 at 12:05 PM, dffdgsdfgsdfhjhtre wrote: > It seems right now, django's documentation is trying to do both at the > same time. One project that does reference documentation really well, > imo, is PHP. For example: http://us3.php.net/preg_replace Say what you > will about PHP, but it's documentation for each function it provides > is top notch. I really wish django had something like that for each > function it provides. Django doesn't have that, but Python does: it's called epydoc and it will happily generate for you a javadoc-style interface for browsing every module, class and function. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: MySQL index hints
On Jul 4, 2010, at 1:10 AM, Simon Litchfield wrote:
> For those of us using MySQL, having large tables, whilst also wanting
> queryset goodness --
> http://code.djangoproject.com/ticket/11003
>
> It goes a little something like this --
> Model.objects.filter(field=value).with_hints('my_index')
>
> All those in favour say I.
A very big aye from here. For a very high traffic project backed by 20+ DB
servers, not being able to hint inline was the #1 reason we had to write
queries by hand for the public-facing portions, and it was a noticeable
percentage of our total public queries (easily >10%).
George
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Sun, Jul 4, 2010 at 2:05 PM, dffdgsdfgsdfhjhtre wrote: > There are two types of documentation, "reference" documentation > (articles explaining all about one specific object such as slugify or > the Feed class), and "topical" documentation (articles explaining how > to do stuff like write templates). > > It seems right now, django's documentation is trying to do both at the > same time. > I agree that sometimes django's documentation can be a mixture of those two kinds, but I think it is not a problem that appears throughout all the docs, but in some rare places. > One project that does reference documentation really well, > imo, is PHP. For example: http://us3.php.net/preg_replace Say what you > will about PHP, but it's documentation for each function it provides > is top notch. I really wish django had something like that for each > function it provides. > I think this kind of documentation is much less important in python projects. Of course it may be useful to have it in a browser window, but I tend to work with a python shell open all the time, so just typing help(function) (or function? in ipython) should give me the docstring and the function signature (and django's docstrings are great in general). > Yesterday I wanted to add the RegexValidator to my project, but > couldn't figure out how to import it because the documentation didn't > mention where the validators lives. I had to resort to googling > "RegexValidator django import" and came across some random pastebin > which had the import, and then went from there. That wasn't the first > time I had to do this. > For this kind of problem, i just grep django's code for the string I want. I know that not everyone likes to do this, and the lack of this kind of docs shouldn't impose a workflow, but since django is open source, and it's code is freely available the need for this kind of very specific documentation is not as obvious. I think what we should so is totally revamp the documentation for the > 1.3 release. I'm willing to do most of the work. I shouldn't be too > hard to do because right now everything is mostly already written, > just not organized very well. > I'm not saying the organization of the documentation can't be improved, but I really don't see the point of having this kind of auto generated documentation when we have great docstrings and resources to access them. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Allow context processors access to current version of context
Hi! I have opened a ticket and would like some feedback on it. Do you think it is a good idea? Ticket description: Allow context processors access to current version of context so that they can change values and not just override them. This can be easily done with another argument, context, and also backwards compatible. Functions would only get additional argument if they are defined to get two arguments and whatever they would return would override that in the context. http://code.djangoproject.com/ticket/13841 Mitar -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Jul 4, 2:22 pm, Flávio Amieiro wrote: > For this kind of problem, i just grep django's code for the string I want. I > know that not everyone likes to do this I may be in the minority here, but I believe grepping source should never, ever, ever be an acceptable substitution for proper documentation. > I'm not saying the organization of the documentation can't be improved, but > I really don't see the point of having this kind of auto generated > documentation when we have great docstrings and resources to access them. Then how else should the docs be re-organized? You seem to be arguing for there being no documentation at all. Should we just put everything into docstrings and tell people to use epydoc and help()? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Sun, Jul 4, 2010 at 8:29 PM, dffdgsdfgsdfhjhtre wrote: > I may be in the minority here, but I believe grepping source should > never, ever, ever be an acceptable substitution for proper > documentation. > I agree with you here. As I said, I don't think this workflow should be imposed on everyone, and I do agree that these should be documented. Then how else should the docs be re-organized? You seem to be arguing > for there being no documentation at all. Should we just put everything > into docstrings and tell people to use epydoc and help()? > I'm saying that the autogenerated documentation I see all around the web in most cases is not the least useful. I'm saying that the documentation has to be more in depth, about how (and specially why) to use something, not just describe a function's arguments and output. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Jul 4, 7:38 pm, Flávio Amieiro wrote: > On Sun, Jul 4, 2010 at 8:29 PM, dffdgsdfgsdfhjhtre wrote: > > > I may be in the minority here, but I believe grepping source should > > never, ever, ever be an acceptable substitution for proper > > documentation. > > I agree with you here. As I said, I don't think this workflow should be > imposed > on everyone, and I do agree that these should be documented. > > Then how else should the docs be re-organized? You seem to be arguing > > > for there being no documentation at all. Should we just put everything > > into docstrings and tell people to use epydoc and help()? > > I'm saying that the autogenerated documentation I see all around the web in > most > cases is not the least useful. I'm saying that the documentation has to be > more in > depth, about how (and specially why) to use something, not just describe a > function's > arguments and output. OK I see what you're saying. I agree with you in that auto documentation usually sucks. What I'm wanting to do is remove all the reference stuff and move it into it's own section so that the topical documentation can be more specialized and concise. There are three types of users of django: Beginners, intermediate, and experts. We should reorganize the documentation to target each type. Beginners who know programming and python well, but don't know Django. These people will need the topical documentation the most because it will explain to them the entire process from a birds eye perspective. Then there are the intermediate users, such as myself, who already know how templates work, how urls are resolved, etc. We don't need the topical documentation as much because we already know that stuff. What we do need is reference. I don't know about you all, but I always have to look up the model field parameters every time I write a model because I can never remember them. Right now I have to load up this page: http://docs.djangoproject.com/en/1.2/ref/models/fields/#ref-models-fields then wade through a ton of stuff because th stuff I'm looking for is mixed with paragraphs and paragraphs of text. Then there are the experts. The core developers and the people who delve in and modify django code itself. Doc strings and "#" documentation should be written for them. Epydoc should be what these people use. They already know what a bit of code does, what is important to them, is how the code worlks. Why a certain under-the- hood metaclass does what it does. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: documentation re-factor for 1.3?
On Sun, 2010-07-04 at 10:05 -0700, dffdgsdfgsdfhjhtre wrote: > There are two types of documentation, "reference" documentation > (articles explaining all about one specific object such as slugify or > the Feed class), and "topical" documentation (articles explaining how > to do stuff like write templates). > > It seems right now, django's documentation is trying to do both at the > same time. One project that does reference documentation really well, > imo, is PHP. For example: http://us3.php.net/preg_replace Say what you > will about PHP, but it's documentation for each function it provides > is top notch. I really wish django had something like that for each > function it provides. Unlike PHP, we have namespaces, which means that providing a list of every function/class is a different matter. But we already do it: http://docs.djangoproject.com/en/dev/genindex/ > Yesterday I wanted to add the RegexValidator to my project, but > couldn't figure out how to import it because the documentation didn't > mention where the validators lives. I had to resort to googling > "RegexValidator django import" and came across some random pastebin > which had the import, and then went from there. That wasn't the first > time I had to do this. With regards to RegexValidator, the main problem is that docs/ref/validators.txt does not use the module directive to indicate which module it is talking about, which is a bug. If it did, then hovering the mouse over the anchor at the end of each class/function identifier reveals the import path. (see things like http://docs.djangoproject.com/en/dev/ref/forms/fields/#django.forms.BooleanField for example). Perhaps this could be more obvious e.g. the module name could also appear at the top of the page. Also, in the index, the location of each class/function is defined, so that if you are looking for something specific, you can indeed find where it lives pretty easily. (Again, it is not correct for RegexValidator at the moment because of the lack of module directive). One problem with documentation is that the more unnecessary detail you add, the harder it becomes to find anything. If you make something too long people won't bother reading anything at all. The noise of user added comments on some PHP function pages is unbearable - not that you were suggesting allowing comments, I'm just saying that excessive quantity kills usefulness. I really did not think that your example documentation for slugify added anything but verbosity to our existing docs. It would not make it easier to find - our index already lists 'slugify' - and is is mainly a whole bunch of boilerplate that should be taken for granted by anyone who understands the basics of Python and the relevant Django subsystem. (And I don't think we should be aiming at an audience any lower than that in our docs). And if you make something 5 times longer but haven't added value, you have made it a lot worse. > Right now the documentation consists of a relatively small number of > pages that are sometimes 50 or 60 screens long (obviously depending on > screen resolution). What I think it better is to have a much larger > number of pages, each only being 10 screens long max. One page for > each model field, one page for each widget type, one page for each > template tag, etc. Then each page can link to the corresponding > "topical" documentation page to see how that function/class/object > relates to the big picture. The problem is that most model fields are very similar, and have common options. So splitting up fields into separate pages makes it harder to find the common options, or means you will end up duplicating a whole bunch of information pointlessly. I'm not against changing things in specific cases, but I'm not keen on the principles behind these changes. Having long pages is not a problem if you've got a fine-grained table of contents and index which will take you right to the relevant place - which we do already, and large pages that collate, for example, all the different fields really help when you don't know exactly what you want, but you're sure you will find something useful in the current module. Finally, some things do not have documentation regarding their import paths because they are not considered public. Even slugify is only 'public' as a template filter, and for that purpose it is a builtin and does not need to be imported. We currently make no guarantee that "from django.template.defaultfilters import slugify" will work in future AFAIK, or that it will be suitable for use outside the template system. (It already has some things, related to auto-escaping, that might make it behave 'funny' depending on what exactly you pass it). I think that a developer wanting to find function that are not publicly documented *is* expected to know how to use grep (or 'ack', which is a great replacement, BTW). Regards, Luke Regards, Luke -- "Underachievement: The tallest blade of grass is the f
Re: documentation re-factor for 1.3?
On Jul 4, 8:40 pm, Luke Plant wrote: > Unlike PHP, we have namespaces, which means that providing a list of > every function/class is a different matter. So? Matplotlib has similar documentation to PHP's reference, and it's fairly well regarded. The one thing that matplotlib doesn't do well is the topical stuff which django does do well. > Also, in the index, the location of each class/function is defined, so > that if you are looking for something specific, you can indeed find > where it lives pretty easily. (Again, it is not correct for > RegexValidator at the moment because of the lack of module directive). I did not know this... Maybe we should have documentation for the documentation > One problem with documentation is that the more unnecessary detail you > add, the harder it becomes to find anything. I agree. > If you make something too > long people won't bother reading anything at all. I agree with this too. This is why I think a lot of the monolithic documentation pages need to be split up. > The noise of user > added comments on some PHP function pages is unbearable - not that you > were suggesting allowing comments, I'm just saying that excessive > quantity kills usefulness. PHP's problem is that they don't moderate their comments at all. They put it at the bottom of the page, so it has never bothered me, but if they were to remove the blatantly wrong posts it would be a lot more helpful. > I really did not think that your example documentation for slugify added > anything but verbosity to our existing docs. It would not make it easier > to find - our index already lists 'slugify' - and is is mainly a whole > bunch of boilerplate that should be taken for granted by anyone who > understands the basics of Python and the relevant Django subsystem. It was a quick example because slugify is a easy thing to document. Other functions could make use of the "input" and "output" sections more correctly, for instance. I only added them to demonstrate what I was aiming at. Also, another great thing about PHP's documentation is that each and every function page is structured the exact same way. You may call it 'boilerplate', but I call it 'consistent structure'. With PHP's documentation, If you know exactly what you're looking for, you can find it very quickly. For instance if you want to look up the order of parameters the preg_replace function takes, you type "preg_replace" into the search box, then move your eyes down to the first pink box. That takes 2 seconds max. For django, if you wanted to know the order of parameters the reverse() function takes, it will take you much longer. Not _too_ much longer, but > (And > I don't think we should be aiming at an audience any lower than that in > our docs). > > And if you make something 5 times longer but haven't added value, you > have made it a lot worse. I'm not saying we should make the documentation longer. I'm proposing we reorganize what we already have into two supersections; reference, and topical, since they are aimed at separate audiences and serve different purposes. > > The problem is that most model fields are very similar, and have common > options. So splitting up fields into separate pages makes it harder to > find the common options, or means you will end up duplicating a whole > bunch of information pointlessly. Not necessarily. Just define one page for all common model field parameters, then link to them from each model field's page. > I'm not against changing things in specific cases, but I'm not keen on > the principles behind these changes. Having long pages is not a problem > if you've got a fine-grained table of contents and index which will take > you right to the relevant place - which we do already, and large pages > that collate, for example, all the different fields really help when you > don't know exactly what you want, but you're sure you will find > something useful in the current module. > > Finally, some things do not have documentation regarding their import > paths because they are not considered public. Even slugify is only > 'public' as a template filter, and for that purpose it is a builtin and > does not need to be imported. We currently make no guarantee that "from > django.template.defaultfilters import slugify" will work in future > AFAIK, or that it will be suitable for use outside the template system. > (It already has some things, related to auto-escaping, that might make > it behave 'funny' depending on what exactly you pass it). Then that should all should be documented! There has to be lots of people out there who use slugify and other template functions outside templates. I don't thionk theres anything wrong with encouraging people to do this as long as you make it clear that these functions can move and that there may be side effects from auto-escaping and such. > I think that > a developer wanting to find function that are not publicly documented > *is* expected to know how to use
Re: Django and the Eyjafjallajökull eruption
Hi Helgi, that's an awesome story. We share your appreciation. Rahul and Ambrish would be really satisfied and motivated if their ibm_db_django adapter was used in this. thanks Mario On Jul 2, 4:03 pm, Helgi Borg wrote: > Remember the Eyjafjallajökull eruption that stopped air traffic over > parts of Europe? The staff at the Icelandic Meterological Office had > a seriously busy time the first days of the eruption. When I arrived > at work the first morning, I quickly realized that we needed a simple > msg-software so the teams of meteorologists, geologists, hydrographers > and the executives could better synchronize their work. In a few > hours, I had implemented, tested and deployed a Django app that helped > a lot. - Django is truly an amazing piece of software. Thank you for > Django! > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django and the Eyjafjallajökull eruption
Could a poll on the mailing lists (and djangopeople.net) be a way to know how important for the django programmers View permission in admin will be? On Sat, Jul 3, 2010 at 09:36, Russell Keith-Magee wrote: > On Fri, Jul 2, 2010 at 7:03 PM, Helgi Borg wrote: >> Remember the Eyjafjallajökull eruption that stopped air traffic over >> parts of Europe? The staff at the Icelandic Meterological Office had >> a seriously busy time the first days of the eruption. When I arrived >> at work the first morning, I quickly realized that we needed a simple >> msg-software so the teams of meteorologists, geologists, hydrographers >> and the executives could better synchronize their work. In a few >> hours, I had implemented, tested and deployed a Django app that helped >> a lot. - Django is truly an amazing piece of software. Thank you for >> Django! > > You're most welcome - and thanks for sharing your story. We've been > meaning to start gathering success stories so that we can show the > world all the interesting ways and places that Django is used. It > would be fantastic to be able to tell the world about success stories > such as yours. > >> The Django app was reasonable good although not perfect. Let me >> explain why… >> >> I needed every user to be able to view messages from anyone. Members >> of the same teams (users of the same Auth. group) needed to be able to >> correct messages from each other for some time until the messages >> automatically locked for changes. >> >> The obvious choose was to use the Contrib Admin. It is robust, fast, >> easy for developers to use, easy for users to get used to and has a >> persistent user interface. In other words it is almost perfect for all >> our data registration usage except that it doesn’t have view >> permissions. The ModelAdmin class would be perfect if it only had view >> permissions (perhaps read permission is a better word). >> >> A dirty solution is to apply change permission to “view only >> permission-users” and then use save_model() to deny these users to >> actually change view-only instances. The practical problem with this >> is that the UI indicates that the user can change something that he/ >> she may not change. >> >> One could argue that I should use something else than Contrib Admin. >> The problem is that there is nothing else as good available. Mixing >> Contrib Admin with other app for view-only purposes results in bad >> usability. Further it doesn’t adhere to the DRY principle to create >> something new when you have something as good as Contrib Admin. >> >> I’ve also created other apps where I’ve needed view permission. These >> are Avalanche registration, Registration of ash fall, Sea ice >> registration, Warning registration and Weather forecasters self >> quality monitoring. Other apps will most likely follow. >> >> I would really appreciate if you could answer the following questions: >> 1) Is there any change that you might consider adding view permissions >> to the Contrib Admin? >> 2) If not, may I ask what the reason is? > > The idea has been proposed in the past: > > [1] http://code.djangoproject.com/ticket/820 > [2] http://code.djangoproject.com/ticket/7150 > > As you can see from those tickets, the historical position has been to > reject the idea. However, it also hasn't been a subject of serious > discussion for a couple of years. There have been a couple of changes > in recent history that suggest to me that there might be scope to > revisit this area -- more details below. > >> 3) Can I add view permissions functionality on top of the Contrib >> Admin without changing its interior, thus avoiding problems on next >> Django update? > > You can always add new permissions without any risk. Django's docs > describe how extra permissions can be defined in the Meta block of a > model [3], but a permission is ultimately just an Django object > itself, so you can create custom permissions manually or > programmatically if you want. > > [3] http://docs.djangoproject.com/en/1.2/topics/auth/#id2 > > However, the admin will only honor the add/edit/delete permissions by > default. If you want admin to honor your custom view permissions, > you'll need to add custom readonly views that check for that > permission. Luckily, you can also add custom views to a standard Admin > install without risk. ModelAdmin allows you to provide a get_urls() > method that exposes custom views. Josh Ourisman's blog post (see his > reply on this thread) shows how this can be done. > >> 4) If not, are there many changes planned for the Contrib Admin on >> next release -- would it be wise for me to add it my self? > > We're still in the process of working out what we will be adding to > Django 1.3, so at the moment, there aren't any firm plans. However, > the broad intention of Django 1.3 is to concentrate less on big > features, and more on bug fixes and smaller features. That doesn't > mean we're not going to add new features -- just that
