On Dec 14, 2006, at 12:49 AM, MC wrote: > > Problem: > I order dates and null values in ascending order under MySQL. To my > surprise, null values are listed first, then actual dates. Turns out > that in MySQL, null values are LOWER than non-null values, whereas > Postgresql is the reverse. As outlined here > http://troels.arvin.dk/db/rdbms/#select-order_by, it seems the only > way > to reverse the order is by prepending a - sign and switching from ASC > to DESC. Unfortunately, this is the same syntax Django uses for > ordering! > > Solution: > I couldn't think of an easy solution through the model API or using > custom managers. I suppose I could write custom SQL, but it would be > nicer to use the model API. I could use a default value like the year > 3000 and filter for display. Any suggestions? Thanks for your help!
Under relational database theory, nulls are not less than or greater than any value, including other nulls. Because of this, you should never count on where a particular database puts those values. The page you quoted explains the allowances that database authors have made to work around the problem. The page didn't even mention sqlite, which follows mysql's convention. I would say this is something that Django should stay away from, too many differences, even more when you include aggregates such as min() and max(). For example in Postgres, min() and max() ignore nulls in columns unless all column values are null, so this behavior is not consistent with its column sorting routines. I think If you want minimum or maximum values in your tables, they should be explicitly coded. Don --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
