couchdb-python vs couchdb trunk
eric casteleijn
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.
--
- eric casteleijn
https://launchpad.net/~thisfred
http://www.canonical.com
Dirkjan Ochtman
casteleijn<eric.ca...@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.
Cheers,
Dirkjan
eric casteleijn
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?
Dirkjan Ochtman
casteleijn<eric.ca...@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.
Cheers,
Dirkjan
eric casteleijn
> On Wed, Jul 15, 2009 at 18:09, eric
> casteleijn<eric.ca...@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.
eric casteleijn
>
> 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...
Dirkjan Ochtman
casteleijn<eric.ca...@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.
Cheers,
Dirkjan
Matt Goodall
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.
- Matt
Christopher Lenz
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 :)
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
eric casteleijn
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.
eric casteleijn
>
> 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.)