couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@couch.io>
Subject Re: Testsuite for HTTP api: questions. And more questions.
Date Tue, 16 Mar 2010 17:29:17 GMT

On Mar 16, 2010, at 8:49 AM, Lena Herrmann wrote:

> Hi!
> 
>>> * Many couch.js methods, like "save" in line 48 for example, take an
>>> "options" hash that goes into the request headers. What different kinds of
>>> options are there for the requestHeaders? I only found out about
>>> "X-Couch-Full-Commit". What does "X-Couch-Persist" do? Are there any more
>>> options?
>>> 
>> 
>> I'm not sure if there's any documentation that enumerates the full
>> list of headers that are used. There aren't too many though. The
>> X-Couch-Persist in particular was invented to allow running the test
>> suite on a modified configuration without writing the new
>> configuration to disk.
> 
> Okay. If someone remembers more options than those two, tell me!
> 
> 
>>> * When I test generated UUIDs, at the moment I just test them to have a
>>> specific length (32 chars), revisions ought to have 34 chars. Is this an
>>> okay approach, or is this length likely to change at some point?
>> 
>> UUID's should be 32 hex characters. I don't see that changing as
>> UUID's are defined as 16 bytes. Revisions on the other hand probably
>> shouldn't be introspected too much. They're meant to be an opaque
>> token that's used for MVCC. Relying on structure or other constraints
>> would violate that.
> 
> Okay. I know test for a revision to have at least 30 characters, nothing else.
> 
> 
>>> * ensureFullCommit - this method only changes the setting on my db instance,
>>> correct? Can I test the db if this setting has been made? (with something
>>> like db.full_commit == true ...)
>>> 
>>> * Was exactly does ensure_full_commit do, once set? There has to be a
>>> definitions somewhere out there ...
>> 
>> If you mean testing the JS object, then I reckon there'd be a way. I'm
>> not entirely sure on how you'd test whether its been taken into effect
>> by the server as its just telling couchdb to do an fsync before
>> returning success.
> 
> Testing the JS object is no problem.
> 
> So to be clear, ensure_full_commit just says "do an fsync and return"?
> 
> 
>>> * Feedback for the spec ".save should save the document with a number as ID"
>>> - I stumbled upon that, I don't know if we want this or not, I think it
>>> would be good.
>> 
>> Not sure I follow. _id's are strings. Saving them as a number would be
>> ungood. Having the JS client auto convert to a string seems like a bad
>> idea.
> 
> Okay.
> 
>>> * If we have a method "deleteDocAttachment", what about "addDocAttachment"
>>> and "openDocAttachment"? For the test I had to replace those - I don't know
>>> if they would be needed in production too, they just seem to miss.
>>> 
>> 
>> I don't follow.
>> 
> 
> No biggie, I was just wondering if "addDocAttachment" and "openDocAttachment" weren't
nice to have. But when no one is missing them, fine.
> 
> 
> 
> Another question:
> 
> * I'm wondering what "setSecObj" does - isn't it to be used to set the "readers" and
"admins" arrays? But when I do this:
> 
> db.setSecObj({'readers':['laura']}); - I get a 500.
> 
> I can set any other keys except "admins" and "readers" though, like:
> 
> db.setSecObj({'something':['laura']}); - works.
> 
> Why is this so?
> Is setSecObj actually supposed to be used for setting something except readers and admins?
> 

You need to call it like this:

db.setSecObj({"readers":{"names":["laura"],"roles":["librarian"]}})

Cheers,
Chris

> 
> Cheers, Lena
> 
> 
> 
> -- 
> http://lenaherrmann.net


Mime
View raw message