this might be easiest to achieve with a an update handler.
you can create all kinds of atomic transactional things like that, on a
single document though.
the user requests the update handler, which updates the count for that
user, and returns the song info, all in one request.
On Sun, Nov 13, 2
You can put it in the user doc or have a third doc. You can't have it on
the song doc, because when many users are writing to it, it will cause rev
mismatch errors.
regds,
mano
Hi Marian
I am still pretty new around here myself, but it seems like what you are doing
is an extension of the blog post & comments model.
http://www.cmlenz.net/archives/2007/10/couchdb-joins
You would just need to extend it a bit to have two references per access object
– one for the song
I personally would create a third "access" doc type. It would have a link
both a song and a user doc.
Hi!
I'm trying to think in CouchDB documents (coming from an SQL
perspective) and I am wondering how I should set up my documents to
represent the following.
I have users who play songs as often as they want. Whenever they
access a song, in the SQL world I add a record to a song_access table
that
Can you tell if you're running Erlang/OTP R14B02 ? There was a change in
that release, related to supervisors, that broke the replicator. CouchDB
1.0.3, and 1.1.0, have code to deal with that change. So, either use one of
these CouchDB releases (or more recent) or use an older Erlang version.
On F
Have also a look at https://github.com/iriscouch/build-couchdb
Marcello
2011/11/12 Stephan Bardubitzki :
> Thanks, will try this tomorrow.
>
> Stephan
>
> On 11-11-11 06:29 PM, Keith Gable wrote:
>>
>> For almost all Unix software, you'd download the source, extract it, and
>> run ./configure --p
