No problem, I'll try and spin up some test db's of various versions next week.
Just to exlpain; the issue is that any date with a year less than 1000 is being output padded with spaces (so year 0001 ends up as u' 1'). This means that serialization is broken for these dates. At the moment as a workaround I've manually patched my django, but just wanted to flag the ticket as marked "ready for checkin". Where/ who would be the best place to direct this? I know things are hectic at the moment with 1.2 etc, should I start another thread here (I don't want to hijack you branch specific stuff any further)? Cheers, Ben On Nov 20, 4:06 pm, Alex Gaynor <[email protected]> wrote: > On Fri, Nov 20, 2009 at 11:03 AM, ben <[email protected]> wrote: > > Hi Alex, > > > I have oracle at work with all versions from 9i to 11. I'd be happy to > > run the tests on all of those verisons. I wonder if I could ask a > > small favour in return though: > > > In our organisation we have a lot of legacy date/time data modeled as > > the year 0001-01-01 and then the time in situations where the time is > > all we're interested in. This is currently causing a headache due to > >http://code.djangoproject.com/ticket/10866which has a patch and is > > ready for checkin. The patch is basically a one character change to > > datetime_safe.py which zero pads dates with year < 1000. Would you > > mind fixing it? > > > Cheers, > > Ben > > > On Nov 20, 3:17 pm, Alex Gaynor <[email protected]> wrote: > >> On Fri, Nov 20, 2009 at 8:26 AM, Karen Tracey <[email protected]> wrote: > >> > On Fri, Nov 20, 2009 at 1:14 AM, Alex Gaynor <[email protected]> > >> > wrote: > > >> >> Hey all, > > >> >> Russ and I have been working on getting the multi-db work ready for > >> >> merge (final stretch here hopefully!), and I just ported the Oracle > >> >> backend to the slightly updated backend arcitecture so it could use > >> >> some testers. If you've got an Oracle setup and can run some tests > >> >> that would be great. You can grab the code here: > > >> >>http://github.com/alex/django/tree/multiple-db > > >> >> Make sure you use the multiple-db branch. I understand running the > >> >> tests under Oracle can be a bit slow, so perhaps start by just running > >> >> the "queries" tests, if they fail please reply with the complete > >> >> tracebacks and such here, otherwise if you have the time a shot at > >> >> running the full test suite would be great. > > >> > The queries test ran OK once I removed: > > >> > from django.db.backends.oracle import query > > >> > from django/db/backends/oracle/base.py > > >> > I guessed based on the fact that django/db/backends/oracle/query.py was > >> > removed in the last commit that the import was leftover from a > >> > restructuring. I am not sure but it looks like there may also be some > >> > other > >> > dead stuff referencing this query module (the query_class method in > >> > DatabaseOperations?), but I did not touch that, just removed that one > >> > import. > > >> > I've got the full suite running now, but that will take a while. > > >> > So far I am testing with just Oracle backend specified. The last time I > >> > tested this branch I also had a test config that specified multiple dbs > >> > -- a > >> > default and an extra one. Not sure if you wanted to test that at this > >> > point > >> > so I started with the simpler one. > > >> > Karen > > >> > -- > > >> > You received this message because you are subscribed to the Google Groups > >> > "Django developers" group. > >> > To post to this group, send email to [email protected]. > >> > 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=. > > >> Just running the Oracle tests is enough for now. I've fixed the error > >> you spotted with the stray import left over and pushed that to github. > > >> Thanks, > >> Alex > > >> -- > >> "I disapprove of what you say, but I will defend to the death your > >> right to say it." -- Voltaire > >> "The people's good is the highest law." -- Cicero > >> "Code can always be simpler than you think, but never as simple as you > >> want" -- Me > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/django-developers?hl=. > > I'm not familiar with that ticket, nor the issues surrounding it, so > I'd be uncomfortable applying a patch in any event, further that > ticket isn't specific to my branch so it should go through the normal > process of being committed to trunk, then I'll happily merge it in. > > Thanks for offering to run the tests! > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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=.
