On Jul 24, 12:26 am, oggie rob <[EMAIL PROTECTED]> wrote: > > > does this also affect psycopg1? > > > Looking at psycopg1 code, the answer would appear to be that it is not > > affected. Changes to support Decimal appear to be psycopg2 specific. > > > Graham > > The problems I was seeing the other day were repeatable both using > strictly psycopg1 (in fact, that was where I first saw the server > error). The issue wrt Decimal is that the Django svn version uses > Decimal and older versions use float, but because psycopg is "cached" > it will convert it into the type that is initialized. In other words, > its not psycopg itself - its the fact that it isn't re-initialized > between requests. > > The recommendation I would make for now is that applications using new > Django builds should use psycopg2 and applications using older builds > should use psycopg1. This way there are two executables that don't > clash in any way. I have done this myself and it eliminated all the > problems I had with float/Decimal compatibility & Unicode.
Hmmm, I'm not sure how psycopg1 in isolation could be a cause of problems as it doesn't anywhere in its source code support the new 'decimal.Decimal' type. Thus, the exact same problem as identified so far with pyscopg2 couldn't be what was being encountered with psycopg1. Looking at the code for psycopg2 again though, it is possible that psycopg2 makes similar mistakes in how it deals with the mxDateTime module as well, as it imports that from module initialiser and caches stuff from it as well. In that case though, the type objects are implemented in C code, unlike 'decimal.Decimal', so that they are shared between sub interpreters I didn't think would cause a problem. How psycopg1 handles mxDateTime is a bit different, but presuming it wouldn't be different. One problem that could arise is if, even in different sub interpreters, two Django instances separately tried to use version 1 and 2 of pyscopg. This is because the Python wrappers for one wouldn't match the loaded C extension module since it is named the same for both versions and would only be loaded once for the whole process. The errors in this case would have been quite dramatic though given the probably significant changes between the API of the C extension module between the two versions. Do you remember the specific Python exceptions you were getting? The Python exceptions which were being encountered when this was originally found were things like isinstance() checks failing because the class type for the instance of a decimal.Decimal didn't match the identity of the decimal.Decimal type from that interpreter, because the instance was creating using the type object from another interpreter. Apart from failure of checks of this sort, the decimal.Decimal instances otherwise worked fine. Looking at the psycopg code, I know there are other problems with the code, but they would only arise where one was doing strange stuff with destroying and recreating Python sub interpreters, a feature that is only possible in mod_wsgi and is unlikely being used by anyone at this point. 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 -~----------~----~----~----~------~----~------~--~---
