Hello,
Based on the research that I've done, CouchDB seems like a very good fit
for the problem I'm trying to solve, but when talking to people from within
the company, they're expressed that there are some unadvertised down sides
to it (though they tried using it 3 years ago) and that we would
1) a stop the world lock when writing to disk
There's no such thing in couchdb. Databases are append-only, there's a
single writer, but concurrent PUT/POST requests are faster than serial
anyway, and each writes to different databases are fully independent.
2) Stack traces are hard to read, not
@Diogo Have you considered using cloudant? :)
On Wed, Nov 20, 2013 at 11:01 AM, Robert Newson rnew...@apache.org wrote:
1) a stop the world lock when writing to disk
There's no such thing in couchdb. Databases are append-only, there's a
single writer, but concurrent PUT/POST requests are
On Nov 20, 2013, at 8:01 AM, Robert Newson rnew...@apache.org wrote:
There's no such thing in couchdb. Databases are append-only, there's a
single writer, but concurrent PUT/POST requests are faster than serial
anyway, and each writes to different databases are fully independent.
And read
I guess this was released from moderation by someone that didn't see
your other email after you subscribed, let's consider this thread
dead?
B.
On 19 November 2013 21:16, Diogo Moitinho de Almeida diogo...@gmail.com wrote:
Hello,
Based on the research that I've done, CouchDB seems like a
And read requests are never, ever blocked, even during a write,
I don't think this is true. A write requires updating views and reads have
to wait for the update. You can tell it to not wait and use stale values
but that impairs consistency.
On Wed, Nov 20, 2013 at 8:56 AM, Jens Alfke
A write requires updating views and reads have to wait for the update
Is not true. Database writes are not coupled to view updates.
Sent from my iPad
On 20 Nov 2013, at 20:59, Mark Hahn m...@reevuit.com wrote:
A write requires updating views and reads have
to wait for the update
Database writes are not coupled to view updates.
I understand now, you are talking about file read/write level. DB reads
are blocked by DB updates at the http level.
On Wed, Nov 20, 2013 at 1:05 PM, Robert Newson robert.new...@gmail.comwrote:
A write requires updating views and reads have
DB reads are blocked by DB updates at the http level.
Nope, there's a process that can read the database and a separate one
for writing to it. Writing to an append only file is obviously
serialized but there's no need to block reads.
B.
On 20 November 2013 21:35, Mark Hahn m...@reevuit.com
When you say blocked... Do you mean time for the view to build? Or waiting
to get a doc out of the database while its being written?.. I thought couch
db was mvcc so there was none of that
On Nov 20, 2013 1:36 PM, Mark Hahn m...@reevuit.com wrote:
Database writes are not coupled to view
never mind. I wasn't talking about the file level at all. I meant that
http read requests are blocked after http update requests.
On Wed, Nov 20, 2013 at 1:52 PM, Robert Newson rnew...@apache.org wrote:
DB reads are blocked by DB updates at the http level.
Nope, there's a process that can
I meant http view requests were blocked. It is waiting for the view
rebuild.
I'm can't type what I'm thinking today.
On Wed, Nov 20, 2013 at 1:54 PM, Mark Hahn m...@reevuit.com wrote:
never mind. I wasn't talking about the file level at all. I meant that
http read requests are blocked
Unless your app can deal with querying the view stale.
On Wednesday, 20 November 2013 at 21:56, Mark Hahn wrote:
I meant http view requests were blocked. It is waiting for the view
rebuild.
I'm can't type what I'm thinking today.
On Wed, Nov 20, 2013 at 1:54 PM, Mark Hahn
True, but remember couchdb doesn't automatically keep indexes fresh in
the background, so stale can be really really stale. ;)
B.
On 20 November 2013 22:34, Simon Metson si...@cloudant.com wrote:
Unless your app can deal with querying the view stale.
On Wednesday, 20 November 2013 at 21:56,
I thought that every write triggered a view rebuild and that the stale
option only meant a read didn't have to wait for a current rebuild to
finish. That would means the views are pretty much up-to-date.
On Wed, Nov 20, 2013 at 2:36 PM, Robert Newson rnew...@apache.org wrote:
True, but
Nope, views are updated on read, hence the blocking behaviour you describe.
You can query with update_after, which returns the stale index then triggers
the update.
On Wednesday, 20 November 2013 at 22:43, Mark Hahn wrote:
I thought that every write triggered a view rebuild and that the
There are, of course, ways to get couchdb to update views dependent on
writes. I also believe this is supposed to get easier in the future
(included in the bigcouch merge?).
Am 20.11.2013 um 23:46 schrieb Simon Metson si...@cloudant.com:
Nope, views are updated on read, hence the blocking
The bigcouch merge will not bring any automatic view updating
scheduler. Nothing stops someone contributing one, of course.
B.
On 20 November 2013 22:49, Mike Marino mmar...@gmail.com wrote:
There are, of course, ways to get couchdb to update views dependent on
writes. I also believe this is
Idk..it sounds hackey.. But curl and crontab is good enough for me for the
views that can't fall more than 1 minute behind
On Nov 20, 2013 2:57 PM, Robert Newson rnew...@apache.org wrote:
The bigcouch merge will not bring any automatic view updating
scheduler. Nothing stops someone contributing
.it sounds hackey.
Just use update_after. It's not a hack.
On Wed, Nov 20, 2013 at 2:59 PM, Stanley Iriele siriele...@gmail.comwrote:
Idk..it sounds hackey.. But curl and crontab is good enough for me for the
views that can't fall more than 1 minute behind
On Nov 20, 2013 2:57 PM, Robert
Idk..it sounds hackey.. But curl and crontab is good enough for me for the
views that can't fall more than 1 minute behind
Depends on your use case, I don't think it's any more hackey than
cron/curl. Crontab is good for scheduling, but if you want to refresh the
view depending on what *actually*
Yeah..it seems that way...but Imagine a scenario where there are a lot of
writes... But few reads... Like...tracking user installs...and queries that
occasionally need to see the number of installs... Unless that query is
being run often... It will fall behind and anyone waiting for it to reindex
Hi,
On Thu, Nov 4, 2010 at 2:16 PM, Trond Olsen tolse...@gmail.com wrote:
So it's like Nicholas mentions, the client becomes responsible for preparing
the data hence also versioning. The server can only validate and cannot
transform a document before it's written?
You could also use couchdb
On Thu, Nov 4, 2010 at 8:08 AM, Trond Olsen tolse...@gmail.com wrote:
I wondered if someone would like to comment on how suitable couchdb would
be
for a webapp I'm developing?
The app functions like a traditional desktop application and I need a
web-based storage solution that users can
2010/11/4 Trond Olsen tolse...@gmail.com:
I wondered if someone would like to comment on how suitable couchdb would be
for a webapp I'm developing?
The app functions like a traditional desktop application and I need a
web-based storage solution that users can subscribe to. The documents to be
Thanks for the answers. I see now I would need to do a lot of customizations
in my case. There's not many restful alternatives for me so I'll need to
experiment with it and see where it leads me.
On Thu, Nov 4, 2010 at 8:40 AM, Nicholas Orr nicholas@zxgen.net wrote:
On Thu, Nov 4, 2010 at
So it's like Nicholas mentions, the client becomes responsible for preparing
the data hence also versioning. The server can only validate and cannot
transform a document before it's written?
On Thu, Nov 4, 2010 at 8:45 AM, Anand Chitipothu anandol...@gmail.comwrote:
2010/11/4 Trond Olsen
I wondered if someone would like to comment on how suitable couchdb would be
for a webapp I'm developing?
The app functions like a traditional desktop application and I need a
web-based storage solution that users can subscribe to. The documents to be
stored would mostly range from 1-10kb with
28 matches
Mail list logo
