On Jul 23, 5:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 7/23/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > > > > > Rather obscure question here. I noted a comment over on the user list > > about SVN version of Django supporting a DecimalField database type. > > What is the relationship between this database field type and any > > particular database adapters ability to store or return values in some > > native database decimal type and convert it to the decimal.Decimal > > type? > > The DecimalField/FloatField change was made on May 20, in [5302] > > The change was made to clarify the FloatField type - the old > implementation was called float field, but used a Decimal as the db > representation. > > In the new code, the DecimalField uses a Python Decimal to store > values internal to Django; a numeric(max_digits, decimal_places) on > the PostgreSQL backend, and converts the Decimal into a string (using > %*.f) for use in any INSERT/UPDATE/SELECT statement. > > When retrieving data for a DecimalField in a SELECT, Django expects > that the response coming from the DB backend will be a Python Decimal. > > More details > here:http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Renam... > > > The reason I am asking is that there were recently problems found with > > pyscopg2 module and its support for use of decimal.Decimal type. In > > practice this only affects people who use mod_python or mod_wsgi and > > run two different Django application instances in two different Python > > sub interpreter instances in the one process. The actual details of > > the pyscopg2 problem can be found at: > > >http://www.initd.org/tracker/psycopg/ticket/192 > > Ok - this is the 'mod_python caching' problem I mentioned on a > different thread the other day. I got a few details wrong at the time, > but please allow me to now gesticulate wildly at the aforementioned > URL, yelling "that one! that one!" :-) > > At the time, I said that we fixed the problem by updating mod_python - > it turns out that I was mistaken. We still have the problem, but we > worked around it by updating some of our Django applications so that a > common Django install was being used. > > > If Django does not use such type conversions done by a database > > adapter module then all would be okay, but if it does some how rely on > > them, I can see in the future some really obscure problems coming up > > if people use psycopg2. > > If I'm understanding the ticket correctly, Django _is_ using the > problematic type conversions. > > Are you able to provide advice/instructions for a workaround for those > using mod_python/mod_wsgi (if such a workaround exists)?
No solution if using mod_python alone. If using mod_wsgi you could leave your main performance oriented Django instance to run in the main Apache child processes (using embedded mode of mod_wsgi) and push secondary instances of Django into distinct daemon processes (using daemon mode of mod_wsgi). In mod_wsgi there is a solution as it allows use of Apache child processes like mod_python as well as daemon processes like with mod_fastcgi. I'll update the Django documentation for mod_wsgi explaining the potential for this problem and include an example configuration. If Django is going to be affected by this, also looks like I better suggest a patch to the pyscopg2 people so it might get fixed sooner rather than later. Thanks for the feedback on Django, I quickly looked at the source code and couldn't see how things hung together myself to know whether it might be affected or not. Graham --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
