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
