#3591 - Custom app_label in Django 1.2?
I don't suppose there's any way to get the patches from ticket #3591 into Django 1.2? If not, can it be marked as definitively not in 1.2 so I can roll a custom solution for myself? It's always hard to tell from the ticket details what stage tickets like that are in. Thanks, Adam -- 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: #3591 - Custom app_label in Django 1.2?
> The patches on this ticket will not land for 1.2. That ticket > contains a series of very large patches, and I don't think a firm > design decision has ever been made about the status of that ticket, > and it was never on the 1.2 feature list. > > Alex > Ok, I'll update the ticket. -- 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: Process discussion: reboot
After reading through this entire thread it seems that there are a few points to be consolidated: 1. DVCS concerns should be pushed to 1.4+ and in the meantime, mirrors are fine. 2. The management of the current Trac system has organizational issues - i.e. many people don't know who committers are and whether they should aggressively manage tickets since they have alot of power. Nonetheless, these are manageable for now. 3. Version 1.3 should be feature-light I would propose the following: 1. Finish version 1.2 2. Assign all of these tickets to 1.3 and nothing else: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=&has_patch=1&order=priority These all have a patch and no milestone. 3. Go through all of the newly assigned 'milestone 1.3' tickets and either close them as wontfix, apply the patch, or move them to a new milestone called 'Next Major Release'. 4. Release version 1.3 5. Evaluate other stuff like major DVCS changes, Trac changes, etc... I think this would be the best timeline for the community and is the best way to maintain a good relationship with the people who have had patches waiting for over a year. Marking them as wontfix is fine, as long as some movement is made. Cheers, Adam On Apr 22, 2:37 am, Thomas Guettler wrote: > The plan to make 1.3 a feature light release with focus on > fixing old bugs and tickets, was a good one. > > I have some tickets in trac which are quite old, too. But it has been > a very long time, since I reviewed tickets of other people, too. > > Sometimes I think the development process is slow. But that's wrong. > The development is just in parts I don't need up to now (for example multi db > support). > > Thomas > > > > > > Jacob Kaplan-Moss wrote: > > Hi folks -- > > > I'd like to try to reboot the discussion that's been going on about > > Django's development process. > > > I'm finding the current thread incredibly demoralizing: there's a > > bunch of frustration being expressed, and I hear that, but I'm having > > trouble finding any concrete suggestions. Instead, the thread has > > devolved into just going around in circles on the same small handful > > of issues. > > > So: here's your chance. You have suggestions about Django's > > development process? Make them. I'm listening. > > > Jacob > > -- > Thomas Guettler,http://www.thomas-guettler.de/ > E-Mail: guettli (*) thomas-guettler + de > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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: Process discussion: reboot
I guess I'll jump in and start triaging. What about a ticket like this: http://code.djangoproject.com/ticket/2284 Super-ambiguous. There are dozens of tickets like this that are frozen in time with no way for anybody to know what's going on. Maybe there just needs to be a better way to handle this type of ticket? Regards, Adam On Apr 22, 4:33 pm, Jeremy Dunck wrote: > On Thu, Apr 22, 2010 at 3:26 PM, Gabriel Hurley wrote: > > On Apr 22, 1:21 pm, Adam Nelson wrote: > > >> 2. Assign all of these tickets to 1.3 and nothing else: > > >>http://code.djangoproject.com/query?status=new&status=assigned&status... > > > A, only 900 tickets to work through for 1.3? Don't go too easy on > > the core team! ;-) > > To be clear, this is why the triage process exists. We need more > people to look at tickets, review them for the standards that Django > has set (good code, test coverage, documentation for any new features) > and mark them "ready for checkin". > > The subset of tickets that achieve "ready for checkin" then take a > commiter's time for final review and merge. > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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: Decision required: PostgreSQL minimum versions
I agree with Simon, Jerome et al. Django 1.3 should feel free to go to 8.3 as a minimum Postgres if there are db backend changes that could take advantage of those versions' capabilities. Ubuntu Hardy (the previous LTS) uses Postgres 8.3 and RHEL 5.5 uses 8.4. It really seems to me that the Django project allows for underlying databases to simply be too old. Django 1.2 will be supported until Django 1.4 is out, so people have the option to continue using 1.2 for a very long time if their organization has an exceedingly long upgrade cycle internally. In my mind, people in such organizations aren't installing Django updates until a year after the release anyway. With that knowledge, I would personally support Django 1.3 having minimums of Postgres 8.3 and MySQL 5.0 (again, if there is actual code written to take advantage of those versions, not just for the hell of it). -Adam Postgres Feature Matrix: http://www.postgresql.org/about/featurematrix MySQL 5.0.51a on Ubuntu Hardy: http://packages.ubuntu.com/hardy/mysql-server-5.0 PostgresSQL 8.3.11 on Ubuntu Hardy: http://packages.ubuntu.com/hardy/postgresql -- 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: Unique CharField greater than 256 characters on MySQL Fails - what is the correct solution
The specific problem was already fixed at http://code.google.com/p/django-app-plugins/issues/detail?id=11 I was speaking of the more general problem about what Pinax's stance with regards to these type of limitations. From the limited feedback, it sounds like our minimum standard will be UTF8 for all applications - which means that apps/libs that can't work on the current stable MySQL using the UTF8 character set would have to be patched in order to be included. As for the indexing of the hash, I think that's kind of overkill. It would reduce the column (including index) size by about 3/4 but it would add processing overhead . Anyway, this is only a table used to hold no more than 100 records since it's just a glue table to connect plugins to eachother. Still, I don't own the app so I don't have write privileges to it. It's bundled into Pinax :-) Thanks, Adam On Oct 19, 11:58 pm, Ian Holsman <[EMAIL PROTECTED]> wrote: > With MySQL it depends on the character set you are creating the table with. > for example with mysql 5.0.45: > > mysql> create table foo ( x varchar(999), primary key (x)) character set > = 'latin1'; > Query OK, 0 rows affected (0.00 sec) > > mysql> create table foo2 ( x varchar(999), primary key (x)) character > set = 'utf8'; > ERROR 1071 (42000): Specified key was too long; max key length is 999 bytes > > mysql> create table foo2 ( x varchar(255), primary key (x)) character > set = 'utf8'; > Query OK, 0 rows affected (0.01 sec) > > So.. if you can live without the benefit of UTF8 you can achieve your > result. > > personally I think you should look at your DB-design, as indexes on > large fields are expensive in terms of space used and time to retrieve > results. you could possibly index the MD5 of the field (32 bytes), and > then search for duplicates on that key. it might be faster and cheaper > on the disk. > > regards > Ian > > Dj Gilcrease wrote: > > The max length of a varchar field is Database dependent > > > MySQL it is 255 > > MSSQL it is 2^31-1 (2gb) > > PostgreSQL it is ~ 2^20-1 (1gb) > > > MySQL 4.1 and greater supposedly changes any varchar or char field > > with a max length or greater to 255 to a TEXT field which can hold ~ > > 1gb > > > Dj Gilcrease > > OpenRPG Developer > > ~~http://www.openrpg.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Proposal: Set minimum MySQL version for Django 1.0
Proposal: After running into numerous 'gotcha' type problems with django-contrib and django-hotclub on MySQL and looking at some of the MySQL code , I'd like to propose that Django have an official minimum MySQL version for the Django core and possibly a higher recommended version for contrib, hotclub, and any portable Django apps/snippets/libraries. Right now, MySQL 3.23 is theoretically supported although I'm quite sure that nobody is using anything lower than 4.0. I'm going to write out my logic in order so that people can simply stop where they disagree, and that can be a good community-minimum. I have opinions about what that minimum should be but at the least, I'd like to get some number out of this and then have that number in the docs. 1) MySQL 3.23 is radically outdated - we really don't need to support 3.23, even informally IMHO. This would fit with the timeline of Django supporting Python 2.3 and up. Python 2.3 was released in July, 2003 - abut when MySQL 4.0 was released. 2) MySQL 4.0 cannot reliably handle unicode. Since Django has made i18n and unicode cornerstones of development, I think it's very dangerous to accept this as a minimum database on any production system. I think it's reasonable to expect code to work on MySQL 4.0 under most circumstances but I don't think time should be spent addressing bugs for such an old version. 3) MySQL 4.1 is largely unicode-friendly. Django-contrib gis wouldn't work on an older database like this, but it most likely should work pretty well. However, virtually nobody uses MySQL 4.1 - it was pretty much a skipped version. 4) MySQL 5.0 is the current production database from MySQL. It was released in December of 2005. In April 2007, it made it into Debian Etch as part of a fully stable release from Debian. As many of you know, when Debian says 'stable', it means that they've tested it for a very long time. This effectively means that any server built in 2008 already has MySQL 5.0 running on it. I propose that we make MySQL 5.0 the standard minimum version for use with Django 1.0. Sites using Django 0.96 and earlier, who are working with extremely long upgrade paths, will need to wait for Django 1.0 to mature before even considering an upgrade at the framework level. For those shops, I'm imagining that they will make the transition some time in the middle of next year or possibly 2010. Because of this, I think we can safely make MySQL 5.0 a minimum since virtually all servers are already using that and anybody who cannot upgrade their database software will likely be in a position where they cannot upgrade Django, etc... Furthermore, with regards to Debian Etch having MySQL 5.0, I would like to define the minimum recommended version as 5.0.32. Any new installation should be using at least this version, which came out 18 months ago. To sum up, I'm proposing: 1. That there is a minimum MySQL version and a recommended minimum MySQL version for Django 1.0 2. That the minimum be MySQL 5.0 (specifically 5.0.15 - the first production version of MySQL 5.0 released October 2005) 3. That the recommended minimum be MySQL 5.0.32 which was released in January of 2007. Advantages include: 1. Geographic methods available out of the box. 2. Strong Unicode capabilities. 3. Clustering and backup options. 4. Large table support. 5. Better standards support. 6. Stored Procs, Views, Cursors, Basic Triggers. I know Postgres is ahead in so many respects on this but as long as MySQL is supported at all, we have to have this conversation. Can ANYBODY who is using MySQL 4.0 or 4.1 on a Django 1.0 system please write in with their comments. I personally think that nobody is even using 4.0 with Django 1.0 - I haven't been able to find anybody yet. This is the command to get the version: > mysqladmin version Regards, Adam 1. http://packages.debian.org/etch/mysql-server - Etch MySQL 2. http://packages.debian.org/sarge-backports/mysql-server - Sarge Backports MySQL 3. http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0.html - MySQL Release notes (5.0.32 was a backport release that isn't in these release notes) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Proposal: Set minimum MySQL version for Django 1.0
After further review, I did find some webhosts that are still using the MySQL 4 series which would be restrictive for some Django 1.0 users. MySQL 4.1 might be a better minimum. http://mediatemple.net/webhosting/gs/faq.php -Adam On Oct 28, 12:29 pm, Adam Nelson <[EMAIL PROTECTED]> wrote: > Proposal: > > After running into numerous 'gotcha' type problems with django-contrib > and django-hotclub on MySQL and looking at some of the MySQL code , > I'd like to propose that Django have an official minimum MySQL version > for the Django core and possibly a higher recommended version for > contrib, hotclub, and any portable Django apps/snippets/libraries. > > Right now, MySQL 3.23 is theoretically supported although I'm quite > sure that nobody is using anything lower than 4.0. I'm going to write > out my logic in order so that people can simply stop where they > disagree, and that can be a good community-minimum. I have opinions > about what that minimum should be but at the least, I'd like to get > some number out of this and then have that number in the docs. > > 1) MySQL 3.23 is radically outdated - we really don't need to support > 3.23, even informally IMHO. This would fit with the timeline of > Django supporting Python 2.3 and up. Python 2.3 was released in July, > 2003 - abut when MySQL 4.0 was released. > 2) MySQL 4.0 cannot reliably handle unicode. Since Django has made > i18n and unicode cornerstones of development, I think it's very > dangerous to accept this as a minimum database on any production > system. I think it's reasonable to expect code to work on MySQL 4.0 > under most circumstances but I don't think time should be spent > addressing bugs for such an old version. > 3) MySQL 4.1 is largely unicode-friendly. Django-contrib gis wouldn't > work on an older database like this, but it most likely should work > pretty well. However, virtually nobody uses MySQL 4.1 - it was pretty > much a skipped version. > 4) MySQL 5.0 is the current production database from MySQL. It was > released in December of 2005. In April 2007, it made it into Debian > Etch as part of a fully stable release from Debian. As many of you > know, when Debian says 'stable', it means that they've tested it for a > very long time. This effectively means that any server built in 2008 > already has MySQL 5.0 running on it. > > I propose that we make MySQL 5.0 the standard minimum version for use > with Django 1.0. Sites using Django 0.96 and earlier, who are working > with extremely long upgrade paths, will need to wait for Django 1.0 to > mature before even considering an upgrade at the framework level. For > those shops, I'm imagining that they will make the transition some > time in the middle of next year or possibly 2010. Because of this, I > think we can safely make MySQL 5.0 a minimum since virtually all > servers are already using that and anybody who cannot upgrade their > database software will likely be in a position where they cannot > upgrade Django, etc... > > Furthermore, with regards to Debian Etch having MySQL 5.0, I would > like to define the minimum recommended version as 5.0.32. Any new > installation should be using at least this version, which came out 18 > months ago. > > To sum up, I'm proposing: > > 1. That there is a minimum MySQL version and a recommended minimum > MySQL version for Django 1.0 > 2. That the minimum be MySQL 5.0 (specifically 5.0.15 - the first > production version of MySQL 5.0 released October 2005) > 3. That the recommended minimum be MySQL 5.0.32 which was released in > January of 2007. > > Advantages include: > > 1. Geographic methods available out of the box. > 2. Strong Unicode capabilities. > 3. Clustering and backup options. > 4. Large table support. > 5. Better standards support. > 6. Stored Procs, Views, Cursors, Basic Triggers. > > I know Postgres is ahead in so many respects on this but as long as > MySQL is supported at all, we have to have this conversation. > > Can ANYBODY who is using MySQL 4.0 or 4.1 on a Django 1.0 system > please write in with their comments. I personally think that nobody > is even using 4.0 with Django 1.0 - I haven't been able to find > anybody yet. This is the command to get the version: > > > mysqladmin version > > Regards, > Adam > > 1.http://packages.debian.org/etch/mysql-server- Etch MySQL > 2.http://packages.debian.org/sarge-backports/mysql-server- Sarge > Backports MySQL > 3.http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0.html- > MySQL Release notes (5.0.32 was a backport release that isn't in these > release notes) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Proposal: Set minimum MySQL version for Django 1.0
Sounds good - thanks for sending that over. I looked high and low for that document and couldn't find it. I'll make suggestions in a documentation ticket. Regards, Adam On Tue, Oct 28, 2008 at 7:34 PM, Russell Keith-Magee <[EMAIL PROTECTED] > wrote: > > On Wed, Oct 29, 2008 at 1:29 AM, Adam Nelson <[EMAIL PROTECTED]> wrote: > > > > Proposal: > > > > After running into numerous 'gotcha' type problems with django-contrib > > and django-hotclub on MySQL and looking at some of the MySQL code , > > I'd like to propose that Django have an official minimum MySQL version > > for the Django core and possibly a higher recommended version for > > contrib, hotclub, and any portable Django apps/snippets/libraries. > > I'm not convinced an 'official minimum' is the right way to handle > this. Like it or not, Django does largely work with MySQL 3.23, and > MySQL 3.23 is still deployed in the wild. There are limitations, to be > sure, but if you're aware of (and are willing to work around) the > myriad issues, there is nothing preventing you from using old versions > of MySQL with Django. > > The docs already contain a description of the potential problems and > limitations, much like the list you compiled: > > http://docs.djangoproject.com/en/dev/ref/databases/ > > If you have any suggestions on how to improve these notes, feel free > to open a ticket with your suggestions. > > > This effectively means that any server built in 2008 > > already has MySQL 5.0 running on it. > > No - it means that any server built in 2008 using Debian Etch has > MySQL 5.0 running on it. There are many operating systems that are not > Debian Etch, and there are many institutions that won't install the > latest version just because it is the latest (even taking into account > Debian's glacial release schedule). For example, just last week I > worked on a brand new server installation... of RedHat Enterprise > Linux 4, with a shiny new MySQL 4.1 on it. Institutional policy often > overrides release schedules, and the larger the organization, the > larger the inertia when it comes to updating versions. > > 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-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Ticket 9483
Henk, I think the best solution is to: A) Do a patch that defaults to the existing functionality and allows for customization (i.e. the ability to pass characters that would go into the regex). And B) Start a ticket and thread to change the title method for Python on the Python developer's group. Django should follow Python in these cases: http://docs.python.org/library/stdtypes.html?highlight=title#str.title Regards, Adam On Wed, Nov 5, 2008 at 10:36 AM, Hanne Moa <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 4, 2008 at 15:26, H. de Vries <[EMAIL PROTECTED]> wrote: > > Well, I searched around and it seems that a lot of people aren't too > > happy with Python's default title() functionality. ( > > > http://muffinresearch.co.uk/archives/2008/05/27/titlecasepy-titlecase-in-python/ > > ) > > > > From a publishing point of view, > > Which publishing point of view? News? Tabloid? Scientific publication? > Fiction? Other? From which country? If English, which English? At what > point in time? Is there a house-style? > > It might be that Python's existing titlecasing reflects international > usage, or Dutch usage (I'm not Dutch). Titlecasing is generally not > used in my country however. So, this is a localization-question > really. > > > HM, helpful computational linguist > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Remove "old docs" message from Django docs
Actually, this is a typical URL from Google: 1. Search "django models" 2. Get http://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs IMHO, the correct solution is an actual 301 (permanent) redirect to take Google and others where the "current" URL of the page is. Unfortunately, the ?from=olddocs querystring is what Google thinks is the definitive model reference. ?from=olddocs needs to still be supported, but if you Google "Django Models", I don't see any reason to be sent to the 0.96 version of the page. The URL should be whatever the current method is. Part of the problem is that the Google sitemap hasn't been updated in 2 years and looks abandoned: http://code.djangoproject.com/log/djangoproject.com/django_website/sitemaps.py This is what I think is best but it will take some work and seems lower priority than actual development: 1. http://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocsshould 301 (permanent) redirect to http://docs.djangoproject.com/en/ref/models/instances - it would be nice if this weren't necessary, but it's too late judging from Google's index. 2. http://docs.djangoproject.com/en/dev/ref/models/instances (with the dev/) should work, but should show the message telling the user that this is the development version of this document with a link to http://docs.djangoproject.com/en/ref/models/instances (without dev/ - the "current" version of the page which is an alias for whatever the current version of the codebase is) 3. http://docs.djangoproject.com/en/1.0/ref/models/instances should work with the 1.0 branch of that document with the same message as #2 giving a link to the person to http://docs.djangoproject.com/en/ref/models/instances. The message here would say something like "This is the absolute URL for this version of this document forever. Unless necessary, please use the current documentation at http://docs.djangoproject.com/en/ref/models/instances. #3 seems redundant but I think it's the best solution to the fact that the current stable documentation lasts only as long as that release. As releases become more common (1.0.1,1.0.2, etc...), this will become more difficult to manage than it ever has been before. If somebody would like, I can start a ticket about this although it will probably take some hashing to figure out the truly correct solution - and I'm not in the best position to implement this. On Tue, Nov 18, 2008 at 8:01 PM, Ludvig Ericson <[EMAIL PROTECTED]>wrote: > > On Nov 19, 2008, at 00:13, Russell Keith-Magee wrote: > > That is exactly what _is_ happening. You only get the olddocs > > parameter if you are visiting from a djangoproject.com/docs URL. If > > you go in via docs.djangoproject.com, you don't get the olddocs > > warning. > > > > The confusion may be caused by the fact that the Google index (which > > is used by Django's documentation search) still contains a lot of > > olddocs pages. > > So uh, I agree with the original post a lot. I personally go edit the > URL all the time so I don't have that big red flashy thing. > > The obvious solution -- to me -- is to do a redirect if the referrer > is not djangoproject.com? To the same URL without the from=olddocs. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: order_by with distinct behavior in orm
A way that might satisfy everybody is to use GROUP BY() and drop DISTINCT. That's a more robust method anyway. So, for a distinct, instead of: SELECT DISTINCT name, (SUBSTRING(name, 1, 3)) AS short_name FROM thing WHERE is_ok = 1 /* Which produces the incorrect values stated above */ Use: SELECT (SUBSTRING(name, 1, 3)) AS short_name FROM thing WHERE is_ok = 1 GROUP BY short_name I think this solution is much more powerful programmatically as it can be extended more easily (i.e. for multi-column uniqueness, aggregate methods). On Wed, Nov 19, 2008 at 7:23 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > > Malcolm Tredinnick wrote: > [...] > > Hopefully, MySQL will fix their bug one day. That's the way to resolve > > this. > > > Just so long as nobody holds their breath waiting ... > > regards > Steve > -- > Steve Holden+1 571 484 6266 +1 800 494 3119 > Holden Web LLC http://www.holdenweb.com/ > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~--~~~~--~~--~--~---
