Sorry, but the value is not included in the ordering of the views, what you’re
seeing there is an artifact of how multiple emits from the same document (where
the emitted key is the same *and* the tie-breaking _id is also the same) are
handled.
B.
On 3 Apr 2014, at 01:52, Rian R. Maloney
Hi folks,
Here's the second edition of the CouchDB Weekly News:
https://blogs.apache.org/couchdb/entry/couchdb_weekly_news_april_3
Get it while it's hot!
Want to help the project out? Do us a favour and spread the news:
Also:
https://twitter.com/CouchDB/status/45166560723968
On 3 April 2014 12:27, Noah Slater nsla...@apache.org wrote:
Hi folks,
Here's the second edition of the CouchDB Weekly News:
https://blogs.apache.org/couchdb/entry/couchdb_weekly_news_april_3
Get it while it's hot!
Want to help
This is incredible, yet again. I can’t believe there is so much going on! :)
Best
Jan
--
On 03 Apr 2014, at 12:27 , Noah Slater nsla...@apache.org wrote:
Hi folks,
Here's the second edition of the CouchDB Weekly News:
https://blogs.apache.org/couchdb/entry/couchdb_weekly_news_april_3
Hi,
is there a reason why it does not appear on planet CouchDB?
Regards
Thomas
On 04/03/2014 12:27 PM, Noah Slater wrote:
Hi folks,
Here's the second edition of the CouchDB Weekly News:
https://blogs.apache.org/couchdb/entry/couchdb_weekly_news_april_3
Get it while it's hot!
Want to help
thanks: very informative
Alex
2014-04-03 14:18 GMT+02:00 Thomas Nunninger tho...@nunninger.info:
Hi,
is there a reason why it does not appear on planet CouchDB?
Regards
Thomas
On 04/03/2014 12:27 PM, Noah Slater wrote:
Hi folks,
Here's the second edition of the CouchDB Weekly
I agree with Jan. Great release. Thanks to everyone that was involved.
On 03 Apr 2014, at 1:30 PM, Jan Lehnardt j...@apache.org wrote:
This is incredible, yet again. I can’t believe there is so much going on! :)
Best
Jan
--
On 03 Apr 2014, at 12:27 , Noah Slater nsla...@apache.org
I have been following this, and was wondering about it.
The documentation doesn't say anything about the second arg (i.e. value) of the
emit call being used for sorting. However it works that way every time, and I
can find no situation where it doesn't happen.
Are you saying that it is NOT
@Thomas Nunninger
we are actually still in the process to reactivate planet.couchdb.org. It
will be eventually consistent :). Please be a little more patient ...
And waves for the next Weekly News :)
Cheers
Andy
On 3 April 2014 15:22, Andy Ellicott a...@cloudant.com wrote:
agreed! Thanks
On Apr 3, 2014, at 5:53 AM, Scott Weber scotty2...@sbcglobal.net wrote:
Are you saying that it is NOT something that should be relied on?
Bob Newson just said that pretty emphatically.
If you want your index to be sorted in a particular way, then emit keys that
sort that way! Don’t try to
You *can* rely on the order of rows with identical keys to be in _id order as
that’s the tie-breaking field.
Other cases where this apparent consideration of value in the sort order is
when views are clustered (ala BigCouch).
Sorting a view by value requires chained map-reduce, presently only
Jens,
Thank you for being so kind, while you were putting statements into my text and
then telling me that I am wrong.
I never said what I was relying on. I was trying to determine if this was a
known behavior becuase it does not seem to appear in any of the no less than
four different sites
to a CouchDB serverI'm literally just executing a unit test 10k times
that open an HTTP connection, post the data and close... CouchDB is performing
very slowly in this. I thought it'd be very fast. Any ideas?
Thanks for the help,
Ken
Are you tearing down the connection and reestablishing it every time? Or
have you played with the TCP_no_delay settings?... Could you define slow
and maybe post your function minus credentials?
On Apr 3, 2014 7:41 PM, Knudsen, Ken
ken.knud...@imaginecommunications.com wrote:
to a CouchDB
System is Windows, 64 bit, V-7...
With delayed_commits on: roughly 40 seconds for 10k
With delayed_commits off...don't ask, way to long.
Why I'm asking (as I've asked in IRC as well)
So why am I doing this... well, the Gods that be don't believe NoSQL (MongoDB,
CouchDB, ArangoDB and so
That's fine..I definitely relate to your situation.. If you want to do 10k
writes...use the bulk_docs API that should do the trick... Bit tearing down
a connection per request will probably not work so well...I just wanted to
see your actual loop or code to verify if its tearing down the
Oh sure.. I was just following the same pattern I did for SQL (all be it a
System.Data.SqlClient driver - C#).. So NUnit Test... Repeat the test 10k times
(RepeatAttribute(1) )... code is..
var httpWebRequest =
(HttpWebRequest)WebRequest.Create(http://137.237.134.94:5984/inserttest/;);
Well for known bulk input you should use the bulk API but in your
case...every test is recreating your client and making that call. I would
try making the request over and over again with the same http client
instead of re running the request over and over again.
In a real live server you would
On Apr 3, 2014, at 8:11 PM, Knudsen, Ken
ken.knud...@imaginecommunications.com wrote:
Oh sure.. I was just following the same pattern I did for SQL
As the name implies, NoSQL databases don’t work the same way as SQL/relational
databases. Part of that is that the APIs are different, and
19 matches
Mail list logo
