OK, here is what I have gathered about the databases listed under DATABASE_ENGINE [4].
Postgresql 8: Supports all three, +/-Inf and NaN [0] MySQL: No support for either NaN or Inf [1] sqlite3: No support for either NaN or Inf [2] Oracle: Supports all three [3] So, we have a 50/50 split. What do you say? - Farhan [0] http://www.postgresql.org/docs/8.2/static/datatype-numeric.html [1] http://dev.mysql.com/doc/refman/5.4/en/numeric-types.html [2] http://www.sqlite.org/datatype3.html [3] http://dev.mysql.com/doc/refman/5.4/en/numeric-types.html [4] http://docs.djangoproject.com/en/dev/ref/settings/#database-engine On Nov 26, 12:24 am, thebitguru <fah...@gmail.com> wrote: > OK, you have me convinced :) My assumption was that the developer > changing these options would take the time to ensure that the database > supports it, but I can see why one might assume that if the API > supports it then the database probably does too. I will do a survey > of the django supported databases to see which support the two cases. > > I hope you feel better (from the cold, that is :)). > > - Farhan > > On Nov 26, 12:09 am, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: > > > > > On Thu, Nov 26, 2009 at 1:52 PM, thebitguru <fah...@gmail.com> wrote: > > > Thanks for the reply, Russ. > > > > I need to revise the patch, but I need some confirmation. I am not > > > sure if it is worth determining what all the different databases > > > support. I think optional parameters (allow_{inf,nan}=False) that let > > > the user specify that django should allow these two cases would be > > > sufficient. Note that I am suggesting setting these to False, which > > > will break compatibility, but I believe that this is really what the > > > average user is expecting anyways. > > > How could it break compatibility? From my testing (i.e., running your > > test cases), passing in NaN or Inf raises exceptions at the moment. At > > this point, it's impossible for any patch dealing with Inf and NaN to > > break backwards compatibility, because there is no working baseline > > behavior. > > > > If I can get a confirmation that this behavior will be acceptable then > > > I will go ahead and submit an updated patch that reflects this > > > change. This time I will ping again in one week :) > > > Adding a configuration doesn't always solve a problem. More often than > > not, it adds a new problem. This is one of those cases. > > > Putting a choice in the hands of a user which can come back and bite > > them is not in the style of Django. Defining a DecimalField with > > allow_inf=True will cause errors if you use a Postgres database. I'm > > not about to commit code that will allow you to have a valid Django > > configuration that throws errors in production. > > > This is why a survey of the current level of support in databases is > > important. If, for example, no database supports Inf, then there is no > > reason to even have an allow_inf setting. If support is varied, then > > we need to have a discussion about the right way to handle the > > variation. > > > There is also the issue of good API design to consider. From a > > practical standpoint, I'm having difficulty thinking of a reason why > > allow_nan needs to exist - why should an end user be allowed to submit > > as a form value that is, a priori, known to be invalid? Essentially, > > you're allowing the user to submit "divide by zero" as a valid form > > value - what is the use case for this? > > > In summary, the process goes like this: > > 1. Get the API right > > 2. Implement it. > > > We're still on step 1. :-) > > > > Enjoy the thanksgiving, > > > Thanks, but FYI: Thanksgiving on the last Thursday in November is a > > US-only holiday. It's held on other dates in some countries, and not > > at all in others. Australia doesn't celebrate Thanksgiving at all. > > > 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.
