Re: Testsuite for HTTP api: questions. And more questions.

[Lena Herrmann <le...@zeromail.org>]

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?


Cheers, Lena



-- 
http://lenaherrmann.net

Re: Testsuite for HTTP api: questions. And more questions.

[J Chris Anderson <jc...@couch.io>]

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