Does anyone have know if couchdb-python is broken with a recent trunk checkout of CouchDB? I'm seeing some very strange behavior in 0.6 in combination with CouchDB trunk, and though this is not the likeliest candidate, I thought I'd ask since I'm running out of other options fast.
If there are known breakages, I'd happily help fix them.
casteleijn<eric.castele...@canonical.com> wrote: > Does anyone have know if couchdb-python is broken with a recent trunk > checkout of CouchDB? I'm seeing some very strange behavior in 0.6 in > combination with CouchDB trunk, and though this is not the likeliest > candidate, I thought I'd ask since I'm running out of other options fast.
Well, couchdb-python-0.6 states compatibility with 0.9.x only, so I wouldn't be surprised (given the development pace of CouchDB trunk) if there are incompatibilities. If you want something that works with couchdb-python-0.6, you should stay on the 0.9 branch of Couch.
Dirkjan Ochtman wrote: > On Wed, Jul 15, 2009 at 17:50, eric > casteleijn<eric.castele...@canonical.com> wrote: >> Does anyone have know if couchdb-python is broken with a recent trunk >> checkout of CouchDB? I'm seeing some very strange behavior in 0.6 in >> combination with CouchDB trunk, and though this is not the likeliest >> candidate, I thought I'd ask since I'm running out of other options fast.
> Well, couchdb-python-0.6 states compatibility with 0.9.x only, so I > wouldn't be surprised (given the development pace of CouchDB trunk) if > there are incompatibilities. If you want something that works with > couchdb-python-0.6, you should stay on the 0.9 branch of Couch.
Yes, I was afraid that would be the answer. Unfortunately I don't have that option, since I need some of the features in CouchDB trunk. Still, does anyone know of or suspect specific areas of incompatibility? I think the bulk updates have changed, and that may be what is causing me trouble now, as I use them quite heavily, but other than that? And if issues are known, are they already (being) addressed in the trunk of couchdb-python?
casteleijn<eric.castele...@canonical.com> wrote: > Yes, I was afraid that would be the answer. Unfortunately I don't have > that option, since I need some of the features in CouchDB trunk. Still, > does anyone know of or suspect specific areas of incompatibility? I > think the bulk updates have changed, and that may be what is causing me > trouble now, as I use them quite heavily, but other than that? And if > issues are known, are they already (being) addressed in the trunk of > couchdb-python?
For one thing, you're not really stating what areas have been problematic, so it's kind of hard to guess where your problem might be. Putting a traceback in here (or explaining the buggy behavior) might go a long way towards getting it fixed.
I haven't seen any commits come by that showed interest in moving past 0.9.x.
Dirkjan Ochtman wrote: > On Wed, Jul 15, 2009 at 18:09, eric > casteleijn<eric.castele...@canonical.com> wrote: >> Yes, I was afraid that would be the answer. Unfortunately I don't have >> that option, since I need some of the features in CouchDB trunk. Still, >> does anyone know of or suspect specific areas of incompatibility? I >> think the bulk updates have changed, and that may be what is causing me >> trouble now, as I use them quite heavily, but other than that? And if >> issues are known, are they already (being) addressed in the trunk of >> couchdb-python?
> For one thing, you're not really stating what areas have been > problematic, so it's kind of hard to guess where your problem might > be.
I'm not getting any errors, and it has been tough going to see what exactly is going wrong, since it's going wrong in the nefarious update notifiers, which are near impossible to debug, but I think I now have it narrowed down to this behavior:
(some?) bulk updates seem to fail silently, but still trigger a database changed event, which triggers my update notifier, which runs a query, sees that it has some processing to do, and does a bulk update. GOTO 10
> Putting a traceback in here (or explaining the buggy behavior) > might go a long way towards getting it fixed.
> I haven't seen any commits come by that showed interest in moving past 0.9.x.
Ok, then I suppose I'll have to bite the bullet, and start a branch myself, I guess. I'll do some experimentation first to see whether the above hunch is correct, and if I see any other problems.
>> I haven't seen any commits come by that showed interest in moving past 0.9.x.
> Ok, then I suppose I'll have to bite the bullet, and start a branch > myself, I guess. I'll do some experimentation first to see whether the > above hunch is correct, and if I see any other problems.
Good news: all the couchdb-python tests in trunk run against couchdb trunk. This can mean one of two things:
1. The particular bulk update is not tested, in which case I shall add a test, and a fix for the problem. 2. The problems I'm seeing are not related to coudhb-python after all, and it just works with trunk.
In either case it's good news for couchdb-python. ;)
Also: I ran the tests in python 2.6 since that's my default python, and that resulted in some very shallow cosmetic fails (all to do with unicode strings vs. normal strings.) At least I think the cause of them was python 2.6. In any case, replacting 'foo' with u'foo' makes everything work. Perhaps the doctest runner itself should be fixed or given an option to ignore these differences (heck, it may already have one.)
I am continuing my investigation into my particular load of fail, and will respond here with any findings relevant to couchdb-python...
casteleijn<eric.castele...@canonical.com> wrote: > Also: I ran the tests in python 2.6 since that's my default python, and > that resulted in some very shallow cosmetic fails (all to do with > unicode strings vs. normal strings.) At least I think the cause of them > was python 2.6. In any case, replacting 'foo' with u'foo' makes > everything work. Perhaps the doctest runner itself should be fixed or > given an option to ignore these differences (heck, it may already have one.)
You should probably open an issue for these, or send a patch to the mailing list.
> On Thu, Jul 16, 2009 at 13:40, eric > casteleijn<eric.castele...@canonical.com> wrote: >> Also: I ran the tests in python 2.6 since that's my default python, and >> that resulted in some very shallow cosmetic fails (all to do with >> unicode strings vs. normal strings.) At least I think the cause of them >> was python 2.6. In any case, replacting 'foo' with u'foo' makes >> everything work. Perhaps the doctest runner itself should be fixed or >> given an option to ignore these differences (heck, it may already have one.)
> You should probably open an issue for these, or send a patch to the > mailing list.
Eric, I assume you're using Ubuntu? ;-)
Jaunty ships with a fairly old simplejson - version 1.9.2. Version 2.x changed the str vs unicode behaviour to gain a bit of performance and that's probably what's causing the failures.
> 2009/7/16 Dirkjan Ochtman <dirk...@ochtman.nl>: >> On Thu, Jul 16, 2009 at 13:40, eric >> casteleijn<eric.castele...@canonical.com> wrote: >>> Also: I ran the tests in python 2.6 since that's my default >>> python, and >>> that resulted in some very shallow cosmetic fails (all to do with >>> unicode strings vs. normal strings.) At least I think the cause of >>> them >>> was python 2.6. In any case, replacting 'foo' with u'foo' makes >>> everything work. Perhaps the doctest runner itself should be fixed >>> or >>> given an option to ignore these differences (heck, it may already >>> have one.)
>> You should probably open an issue for these, or send a patch to the >> mailing list.
> Eric, I assume you're using Ubuntu? ;-)
> Jaunty ships with a fairly old simplejson - version 1.9.2. Version 2.x > changed the str vs unicode behaviour to gain a bit of performance and > that's probably what's causing the failures.
Plus the simplejson version in Python 2.6 is also the older version.
Specifically, in simplejson 2.0.1, the string handling was changed so that unicode objects are only created when necessary (i.e. for strings outside the 7-bit ASII range). See http://bob.pythonmac.org/archives/2008/09/29/simplejson-201/ which includes this quote:
"I'm not aware of any scenario other than doctests where this could be a problem."
:P
If anyone has an idea on how to make the doctests compatible with both versions, *without* adding much (or any) noise to the test code (they are primarily for documentation purposes, after all), I'm all ears :)
Matt Goodall wrote: > 2009/7/16 Dirkjan Ochtman <dirk...@ochtman.nl>: >> On Thu, Jul 16, 2009 at 13:40, eric >> casteleijn<eric.castele...@canonical.com> wrote: >>> Also: I ran the tests in python 2.6 since that's my default python, and >>> that resulted in some very shallow cosmetic fails (all to do with >>> unicode strings vs. normal strings.) At least I think the cause of them >>> was python 2.6. In any case, replacting 'foo' with u'foo' makes >>> everything work. Perhaps the doctest runner itself should be fixed or >>> given an option to ignore these differences (heck, it may already have one.) >> You should probably open an issue for these, or send a patch to the >> mailing list.
> Eric, I assume you're using Ubuntu? ;-)
> Jaunty ships with a fairly old simplejson - version 1.9.2. Version 2.x > changed the str vs unicode behaviour to gain a bit of performance and > that's probably what's causing the failures.
heh, yes, that would be it then: I ran the tests in a clean virtualenv python, whereas in our developers dependencies we have a more recent version of simplejson.
> Plus the simplejson version in Python 2.6 is also the older version.
> Specifically, in simplejson 2.0.1, the string handling was changed so > that unicode objects are only created when necessary (i.e. for strings > outside the 7-bit ASII range). See http://bob.pythonmac.org/archives/2008/09/29/simplejson-201/ > which includes this quote:
> "I'm not aware of any scenario other than doctests where this could > be a problem." > :P
> If anyone has an idea on how to make the doctests compatible with both > versions, *without* adding much (or any) noise to the test code (they > are primarily for documentation purposes, after all), I'm all ears :)
Ok, that's a minor inconvenience then. I don't see a great solution for having doctests that work with both (other than making doctests not care about the difference for plain ASCII strings, like python doesn't.)
