On Thu, Jun 30, 2011 at 8:08 AM, Dale Harvey wrote:
> I
> think its fine to use POST as long as you aware of the idempotent issue
IMHO:
PUT is more informative in client logs
PUT is more informative in server logs
PUT is harder to screw up, because you front-load the hard part:
getting some ids
On Wed, Jun 29, 2011 at 12:06 PM, Christian Carter wrote:
> Hey Everyone,
>
> I'm getting a very weird error when running one of my list functions,
> leading me to believe the query server is crashing, but I don't know for
> sure. Log and function located at http://pastie.org/2138189. The
> data
On Wed, Jun 29, 2011 at 5:56 PM, Dave Cottlehuber wrote:
> On 30 June 2011 05:06, Christian Carter wrote:
> > Hey Everyone,
> >
> > I'm getting a very weird error when running one of my list functions,
> > leading me to believe the query server is crashing, but I don't know for
> > sure. Log an
If these three points are more or less correct ...
1) CouchDB keeps appending to the end of the file. Fine.
2) It needs just as much disk space when doing a compaction. Is that
extra space equivalent to the original uncompacted or the final
compacted version?
3) Compaction is similar to replic
I think what many people really concerned is the growing pattern of size as
number of docs increase. (space complexity)
(If it grows exponentially then that's not a good sign.)
So is there any official/non-official, theoretically/benchmark showing this
characteristic?
2011/6/30 Paul Davis
>
> Te
CouchDB generates uuid's that attempts to minimise the amount of rebalancing
that needs to happen on insert, however thats only an optimization I would
worry about if you are under fairly severe load.
If your application has natural id's then I would use them, if not then I
think its fine to use P
One of the primary supposed advantages of Erlang is its ability to
parallelise.
Has this promise been realised as a performance and scalability
benefit in CouchDB? Or has the promise turned out to be too
impractical to realise in any major way.
as
I was about to post some of what Paul just did
On mobile devices the bottlenecks are in CPU and flash storage, erlang (and
therefore couch) dont have a true idle state, but they do very well at
limiting battery usage on devices, the Android version is now down to 4/5 MB
of flash storage which is c
On Jun 29, 2011, at 4:59 PM, Zdravko Gligic wrote:
> In many places I have read how Erlang runs on small devices and how
> (as a result) it is very frugal with resources. I think that I have
> read that or at least something to that effect.
I’m not an Erlang expert, but the “typical” use-case E
On Wed, Jun 29, 2011 at 7:59 PM, Zdravko Gligic wrote:
> Hi Folks,
>
> In many places I have read how Erlang runs on small devices and how
> (as a result) it is very frugal with resources. I think that I have
> read that or at least something to that effect. However, none of that
> seems to appl
I'm having some trouble getting my ruby restclient to do a _bulk_docs
(delete) post correctly
Version: CouchDb 1.1
RestClient 1.6.3
I get a
abstract_response.rb:48:in `return!': 500 Internal Server Error
(RestClient::InternalServerError)
or
abstract_response.rb:48:in `return!': 415 U
Hi Folks,
In many places I have read how Erlang runs on small devices and how
(as a result) it is very frugal with resources. I think that I have
read that or at least something to that effect. However, none of that
seems to apply to CouchDB.
I believe that I read somewhere that the length of k
On 30 June 2011 05:06, Christian Carter wrote:
> Hey Everyone,
>
> I'm getting a very weird error when running one of my list functions,
> leading me to believe the query server is crashing, but I don't know for
> sure. Log and function located at http://pastie.org/2138189. The database
> can be
Yes, this is a bug in etag generation, not a concerted effort to make them weak.
Sane solution sounds sane.
On Wed, Jun 29, 2011 at 2:54 PM, Robert Newson wrote:
> I think the sanest fix is to make view etags for include_docs=true use
> the original algorithm, so that they always change if the d
On Jun 29, 2011, at 11:54 AM, Robert Newson wrote:
> I think the sanest fix is to make view etags for include_docs=true use
> the original algorithm, so that they always change if the database
> changes. If you file a ticket, I can fix this in the morning.
OK! Filed https://issues.apache.org/jir
I think the sanest fix is to make view etags for include_docs=true use
the original algorithm, so that they always change if the database
changes. If you file a ticket, I can fix this in the morning.
B.
On 29 June 2011 19:22, Jens Alfke wrote:
>
> On Jun 29, 2011, at 11:13 AM, Jens Alfke wrote:
On Jun 29, 2011, at 11:13 AM, Jens Alfke wrote:
> So for example, I do this:
>
> $ curl -I http://localhost:5984/demo-addresses/_all_docs
Sorry, to be a good test the URL should have been like
http://127.0.0.1:5984/demo-addresses/_changes?include_docs=true
because without include_docs,
On Jun 29, 2011, at 8:02 AM, Robert Newson wrote:
> This is deliberate ("COUCHDB-799 - More granular ETags for views." --
> "ETags for views now only change when their underlying view index
> changes due to indexing or purges. ETags are also specific to each
> view.")
>
> The view is updated if
The view result is here:
http://pastie.org/2140812
and the
Christian Carter
612.327.5292
On Wed, Jun 29, 2011 at 12:28 PM, Jan Lehnardt wrote:
>
> On 29 Jun 2011, at 19:06, Christian Carter wrote:
>
> > Hey Everyone,
> >
> > I'm getting a very weird error when running one of my list functions,
On 29 Jun 2011, at 19:06, Christian Carter wrote:
> Hey Everyone,
>
> I'm getting a very weird error when running one of my list functions,
> leading me to believe the query server is crashing, but I don't know for
> sure. Log and function located at http://pastie.org/2138189. The database
> c
Hey Everyone,
I'm getting a very weird error when running one of my list functions,
leading me to believe the query server is crashing, but I don't know for
sure. Log and function located at http://pastie.org/2138189. The database
can be cloned from cdcarter.iriscouch.com/illi, as well. The cra
> For me the most interesting aspect of this posting was
>
> "The only thing that's confusing me is how the VM even started if it's
> unable to read these files."
>
> and that the thread was unresolved.
David,
As it turns out the cause of the issue I was reporting was totally
unrelated and ended
This is deliberate ("COUCHDB-799 - More granular ETags for views." --
"ETags for views now only change when their underlying view index
changes due to indexing or purges. ETags are also specific to each
view.")
The view is updated if and only if the emitted data actually changes.
B.
On 29 June 2
On Tue, Jun 28, 2011 at 4:24 PM, Nils Breunese wrote:
> Benoit Chesneau wrote:
>
>> On Tue, Jun 28, 2011 at 2:54 PM, Nils Breunese wrote:
>>>
>>
>>> (...)
>>>
>>> But sadly make failes:
>>>
>>>
>>> $ cd erica
>>> $ make
>>> Uncaught error in rebar_core: {'EXIT',
>>>
I quote from
Wed Oct 14 20:50:05 CEST 2009
"Erlang on EC2 - Filesystem errors? from Paul Davis
Hey list, I've got a bit of a head scratcher.
The basic premise is trying to run
Erlang on an EC2 sometimes results in errors like those pasted below.
I've seen this type of error from two different C
Hi Behrad,
can you open an issue for this? http://issues.apache.org/jira/browse/COUCHDB
Cheers
Jan
--
On 29 Jun 2011, at 13:02, Behrad Zari wrote:
> Dear Couchees,
> Consider a view on a CouchDB 1.1 private DB which emits: ( doc._id, 1 )
> 1) call the view with reduce=false&include_docs=true b
Dear Couchees,
Consider a view on a CouchDB 1.1 private DB which emits: ( doc._id, 1 )
1) call the view with reduce=false&include_docs=true by your browser!
2) update a document (with futon)
3) recall that view
You will see a cached-inconsistent document included in view results!
(according to _r
27 matches
Mail list logo
