couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lena Herrmann <l...@zeromail.org>
Subject Re: Testsuite for HTTP api: questions. And more questions.
Date Tue, 16 Mar 2010 13:49:32 GMT
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

Mime
View raw message