ResourceNotFound - what is it now?

773 views
Skip to first unread message

almacmillan

unread,
Jul 15, 2010, 8:08:49 AM7/15/10
to CouchDB-Python
Hi

I have been playing around with a couchdb + django tutorial and it
works except when it is looking for:

"ResourceNotFound"

I can't find reference to that in couchdb.client. Has it changed/been
renamed? How should I adjust my code?

Kind thanks
AL

Code:

from django.http import Http404,HttpResponseRedirect
from django.shortcuts import render_to_response
from couchdb import Server
from couchdb.client import ResourceNotFound

SERVER = Server('http://127.0.0.1:5984')
if (len(SERVER) == 0):
SERVER.create('docs')

def index(request):
docs = SERVER['docs']
if request.method == "POST":
title = request.POST['title'].replace(' ','')
docs[title] = {'title':title,'text':""}
return HttpResponseRedirect(u"/doc/%s/" % title)
return render_to_response('couch_docs/index.html',{'rows':docs})

def detail(request,id):
docs = SERVER['docs']
try:
doc = docs[id]
except ResourceNotFound:
raise Http404
if request.method =="POST":
doc['title'] = request.POST['title'].replace(' ','')
doc['text'] = request.POST['text']
docs[id] = doc
return render_to_response('couch_docs/detail.html',{'row':doc})

Matt Goodall

unread,
Jul 15, 2010, 8:16:52 AM7/15/10
to couchdb...@googlegroups.com
On 15 July 2010 13:08, almacmillan <a.w.ma...@gmail.com> wrote:
> Hi
>
> I have been playing around with a couchdb + django tutorial and it
> works except when it is looking for:
>
> "ResourceNotFound"
>
> I can't find reference to that in couchdb.client. Has it changed/been
> renamed? How should I adjust my code?

It's in the couchdb.http module now.

it's also exported in the couchdb package namespace (with the other
common exception types) if you're using recent development code but
that's not been released yet.

>>> import couchdb
>>> couchdb.ResourceNotFound
<class 'couchdb.http.ResourceNotFound'>

- Matt

Dirkjan Ochtman

unread,
Jul 15, 2010, 8:26:48 AM7/15/10
to couchdb...@googlegroups.com
On Thu, Jul 15, 2010 at 14:16, Matt Goodall <matt.g...@gmail.com> wrote:
> it's also exported in the couchdb package namespace (with the other
> common exception types) if you're using recent development code but
> that's not been released yet.

As for that, we should try some test runs on 1.0.0 and 0.11.1 and
release it again.

Do you know of any show stoppers?

Cheers,

Dirkjan

almacmillan

unread,
Jul 15, 2010, 9:00:34 AM7/15/10
to CouchDB-Python
Thanks so much Matt

On Jul 15, 1:16 pm, Matt Goodall <matt.good...@gmail.com> wrote:

Matt Goodall

unread,
Jul 15, 2010, 9:37:55 AM7/15/10
to couchdb...@googlegroups.com

I don't know of any show stoppers although I'm seeing intermittent
failures (i.e. sometimes it passes, sometimes it fails in a different
place) testing against the 0.10.x, 0.11.x, and 1.0.x branches :/.

I'm not sure what the 0.10.x failure is but it's occasionally causing
a conflict error in the test_wrapper_rows and test_wrapper_iter tests.
I'll take a look in a moment.

I have a strong suspicion that the 0.11.x and 1.0.x failures are to do
with async file deletion changes in the 0.11.1 release: "Make file
deletions async to avoid pauses during compaction and db deletion".
We're using the same database name for all tests so if the tests are
running too quickly we're likely hitting race conditions. Certainly,
all the failures I'm seeing are related to database files either not
existing or already existing.

Or of course, it could all just be my computer playing up ;-).

So, I'd like to take a quick look at the 0.10.x failure in case I
messed something up. However, I can't see any changes in the commit
history since our 0.7 release that are likely to cause the 0.11.x and
1.0.x failures so I would personally be happy enough to ignore those
for the purpose of getting a release out.

- Matt

Matt Goodall

unread,
Jul 15, 2010, 11:56:57 AM7/15/10
to couchdb...@googlegroups.com
On 15 July 2010 14:37, Matt Goodall <matt.g...@gmail.com> wrote:
> On 15 July 2010 13:26, Dirkjan Ochtman <dir...@ochtman.nl> wrote:
>> On Thu, Jul 15, 2010 at 14:16, Matt Goodall <matt.g...@gmail.com> wrote:
>>> it's also exported in the couchdb package namespace (with the other
>>> common exception types) if you're using recent development code but
>>> that's not been released yet.
>>
>> As for that, we should try some test runs on 1.0.0 and 0.11.1 and
>> release it again.
>>
>> Do you know of any show stoppers?
>
> I don't know of any show stoppers although I'm seeing intermittent
> failures (i.e. sometimes it passes, sometimes it fails in a different
> place) testing against the 0.10.x, 0.11.x, and 1.0.x branches :/.
>
> I'm not sure what the 0.10.x failure is but it's occasionally causing
> a conflict error in the test_wrapper_rows and test_wrapper_iter tests.
> I'll take a look in a moment.

OK, there's something wacky going on. It's failing at
http://code.google.com/p/couchdb-python/source/browse/couchdb/tests/client.py#580.
I've added debugging so I know the database is getting deleted and
recreated just fine. However, when it fails with a conflict the 'foo'
doc that already exists is at revpos 3 ... which is impossible in a
fresh database.

I'm fairly sure this is also to do with reusing a deleted database
name. If I change the tests to use randomly generated names the
intermittent failures disappear (probably ;-)) for all version of
couchdb.

It would be good if others could run the tests too, but I think it's
ok to release as long as nothing else comes up. At this point, my only
real concern is why the failures, particularly in 0.10.x, have just
started showing up.


- Matt

Dirkjan Ochtman

unread,
Jul 16, 2010, 5:18:20 AM7/16/10
to couchdb...@googlegroups.com
On Thu, Jul 15, 2010 at 17:56, Matt Goodall <matt.g...@gmail.com> wrote:
> It would be good if others could run the tests too, but I think it's
> ok to release as long as nothing else comes up. At this point, my only
> real concern is why the failures, particularly in 0.10.x, have just
> started showing up.

Hmm, I just ran tests against 1.0.0 with tip, and got 0 and 1 failures
in two runs.

The failure I see is in test_changes_releases_conn and seems to have
something to do with authentication. Comes with an Erlang trace, but
it's not stable.

======================================================================
ERROR: test_changes_releases_conn (couchdb.tests.client.DatabaseTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/djc/src/couchdb-python/couchdb/tests/client.py", line
136, in setUp
self.server.delete('python-tests')
File "/home/djc/src/couchdb-python/couchdb/client.py", line 203, in delete
del self[name]
File "/home/djc/src/couchdb-python/couchdb/client.py", line 125, in
__delitem__
self.resource.delete_json(validate_dbname(name))
File "/home/djc/src/couchdb-python/couchdb/http.py", line 386, in delete_json
status, headers, data = self.delete(*a, **k)
File "/home/djc/src/couchdb-python/couchdb/http.py", line 370, in delete
return self._request('DELETE', path, headers=headers, **params)
File "/home/djc/src/couchdb-python/couchdb/http.py", line 418, in _request
credentials=self.credentials)
File "/home/djc/src/couchdb-python/couchdb/http.py", line 309, in request
raise ServerError((status, error))
ServerError: (500,
("{undef,[{gen_server,send_result,[{<0.12782.0>,#Ref<0.0.1.24844>},not_found]},\n
{couch_server,'-handle_call/3-lc$^0/1-0-',1},\n
{couch_server,handle_call,3},\n {gen_server,handle_msg,5},\n
{proc_lib,init_p_do_apply,3}]}", '{gen_server,call,\n
[couch_server,\n {delete,<<"python-tests">>,\n
[{user_ctx,\n {user_ctx,null,\n
[<<"_admin">>],\n <<"{couch_httpd_auth,
default_authentication_handler}">>}}]},\n infinity]}'))

Cheers,

Dirkjan

Matt Goodall

unread,
Jul 16, 2010, 6:00:31 AM7/16/10
to couchdb...@googlegroups.com

Not seen that one here. Once again, it's related to database deletion
although the authentication handler bit is interesting.

I've just pushed some improved tests that don't reuse the same
database name. I cannot get the tests to fail here now (0.10.x,
0.11.x, 1.0.x) but then it was intermittent anyway.

- Matt

Reply all
Reply to author
Forward
0 new messages