I was inspired to some atomicity testing with transactions and couchdb, and
testing under race conditions.

I from this blog entry -

http://blog.codekills.net/2014/03/13/atomic-bank-balance-transfer-with-couchdb/

Firstly, I am having problems getting the concept working and want to be
sure I understand the nature of views correctly.

Firstly, I am working with a single node. So, no possibility for
replication delay issues etc.

Secondly, I understand there can be 3 options when working with views -
default, stales=ok, update-after.

I have not set "stales=OK", or "update after", therefore I assume I am
working with the default behaviour of views.

I am interested with the "oldest pending" view example as shown in the blog
- in particular the reduce portion. That view will show the transaction
with the oldest timestamp.

I understand that the default behaviour when I call a view - the view will
recalculate *at that point in time*, and may even take a while depending on
the amount of documents involved. There should be no risk of stales?

I am testing against race conditions. I wrote a small piece of code to
insert a document which includes an amount and timestamp, I then
immediately call the view. When I say immediately - it could be within 1ms
of inserting a document. Will the "oldest pending" view result be accurate?
Will the document I inserted 1ms earlier be taken in account when calling
the view?

Thank you.

Reply via email to