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
