Congrats Alexander; a very passionate and intelligent engineer that CouchDB
is lucky to have engaged.
On Fri, Feb 21, 2014 at 1:08 PM, Noah Slater wrote:
> Dear community,
>
> I am delighted to announce that Alexander Shorin joins the Apache
> CouchDB Project Management Committee today.
>
> Ale
[
https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616242#comment-13616242
]
Riyad Kalla commented on COUCHDB-1754:
--
Fair point; I think we could profile c
[
https://issues.apache.org/jira/browse/COUCHDB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616229#comment-13616229
]
Riyad Kalla commented on COUCHDB-1754:
--
There might be two interesting
Robert, to your point, when would you copy an entire DB to another live
server and *not* have the intention of the two be replicas of each other?
The UUID would be akin to a social-security-number for the docs, so if I
have a doc "A" in Server1 with a SSN of "333-90-3231", and that same doc
existe
ing, or if I am just enjoying the smell of my own farts over here ;)
-R
On Mon, Jan 23, 2012 at 1:39 AM, Paul Davis wrote:
> On Mon, Jan 23, 2012 at 2:26 AM, Randall Leeds
> wrote:
> > On Sun, Jan 22, 2012 at 04:49, Riyad Kalla wrote:
> >> In my ever-growing need to ask t
In my ever-growing need to ask the most esoteric file-format questions
possible, I am curious if anyone can point me in the direction of the
answer here...
Background
-
Consider the _id and _seq B+ indices whose change-paths are appended to the
end of the Couch data file after ever
I know this discussion took place sometime after the last release; but was
it decided which platform binaries would be provided for the upcoming 1.2
release to help ease adoption?
-R
On Mon, Jan 9, 2012 at 4:24 PM, Noah Slater wrote:
> If a bug is marked as fixed in X version, does that not pr
in beaten horse bodies ;)
I just find this category of problems interesting.
On Thu, Dec 22, 2011 at 6:10 PM, Randall Leeds wrote:
> On Thu, Dec 22, 2011 at 12:11, Riyad Kalla wrote:
> > On Thu, Dec 22, 2011 at 12:38 PM, Robert Newson
> wrote:
> >
> >> There are a
On Thu, Dec 22, 2011 at 12:38 PM, Robert Newson wrote:
> It reads well as an article but needs some polish before it could be a
> great wiki page. I suggest that if it does go up, it is clearly marked
> as a draft, and we all chip in to sculpt it into shape.
>
Great idea. Agreed that it is no wh
the
> data
> >> so the main thing that impacts the branching at each level are the key
> size
> >> and in the case of views the sizes of the reductions as these are stored
> >> with the intermediate nodes.
> >>
> >> All in all it works pretty well
7;ve opened a ticket for.
>
> Cheers,
>
> Bob
>
>
> [1] https://github.com/oreilly/couchdb-guide/issues/450
>
>
>
>
> On Dec 21, 2011, at 3:28 PM, Riyad Kalla wrote:
>
> > Bob,
> >
> > Really appreciate the link; Rick has a handful of article
what the limits are.
>
> Regards,
>
> Bob
>
>
> [1] http://horicky.blogspot.com/2008/10/couchdb-implementation.html
>
>
>
>
> On Dec 21, 2011, at 2:17 PM, Riyad Kalla wrote:
>
> > Adding to this conversation, I found this set of slides by Chris
> explaining
index path duplication would be like).
Can anyone confirm/deny/correct this assessment? I want to make sure I am
on the right track understanding this.
Best wishes,
Riyad
On Tue, Dec 20, 2011 at 6:13 PM, Riyad Kalla wrote:
> @Filipe - I was just not clear on how CouchDB operated; you and Ro
t what or how and that is what I was
hoping for help with.
Much thanks guys, I know this is a heavy question to ask.
Best wishes,
R
On Tue, Dec 20, 2011 at 1:35 PM, Robert Dionne wrote:
>
> Robert Dionne
> Computer Programmer
> dio...@dionne-associates.com
> 203.231.9961
>
f it wrote about it in depth and so far haven't found
anything as detailed as I am hoping for on this architecture.
Best,
Riyad
On Tue, Dec 20, 2011 at 1:07 PM, Filipe David Manana wrote:
> On Tue, Dec 20, 2011 at 6:24 PM, Riyad Kalla wrote:
> > I've been reading everythi
I've been reading everything I can find on the CouchDB file format[1] and
am getting bits and pieces here and there, but not a great, concrete,
step-by-step explanation of the process.
I'm clear on the use of B+ trees and after reading a few papers on the
benefits of log-structured file formats, I
REF:
http://www.h-online.com/open/news/item/Canonical-dropping-CouchDB-from-Ubuntu-One-1382809.html
> Lenton says Canonical has worked with "the company behind CouchDB" to
make the database scale
> in a particular way. "Our situation is rather unique and we were unable
to resolve some of the issue
at 11:11 AM, Riyad Kalla wrote:
> > I believe trunk now utilizes the C JSON parser for some nice speed
> > improvements and thought this might be worth sharing.
> >
> > Over on the JSON spec list two devs were sharing attempts at writing the
> > fastest JSON
I believe trunk now utilizes the C JSON parser for some nice speed
improvements and thought this might be worth sharing.
Over on the JSON spec list two devs were sharing attempts at writing the
fastest JSON parsers in C and C++ respectively.
UltraJSON (C) claims to have the fastest parsing speed
This is an aside and also a "you guys rock" to the CouchDB dev team... I
watched a talk by Benjamin Anderson at Meteor today:
http://www.dataversity.net/archives/6714?t=1320768580
where he talked about their experience with running CouchDB (via Cloudant)
for 2 years in production, scaling from wha
>
> I don't think that this is too big a problem.
It is, it really is.
Many of you are too close to the problem to see it, but the 10-second
impression when you step into the Couch world (as compared to Mongo, Redis,
Orient, Raven or even Cassandra) is "... where do I download and run this
thing
Hmm, I see what you mean. If a single connection isnt pegging any of the
hardware and multiple connections are a magnitude times faster, I am not sure
what would be keeping the single connection from performning faster.
Maybe someone else can hop in with ideas?
R
On Oct 26, 2011, at 4:32 PM,
Konstantin,
What happens when you set delayed_commits to true? With that off you are
requiring an fsync (iirc) after every value written and then are at the
mercy at your disks write performance (but not in the sense of burst-write
as these are individual, disparate write requests coming in).
Al
I'd be happy to sponsor getting this work into CouchDB proper if anyone was
interested.
On Tue, Oct 11, 2011 at 10:59 PM, Dominic Tarr wrote:
> okay, interesting.
>
> that sounds a bit more difficult than the parser! but nevertheless the
> right
> approach.
>
> I'll admit now that I do not know e
[
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121871#comment-13121871
]
Riyad Kalla commented on COUCHDB-1302:
--
Now is the perfect opportunity to
Tim's work is certainly the catalyst for my excitement about the potential
here for Couch.
As Paul pointed out, the correct discussion to have at this point is really
about "do we support a binary format for responses" and if so "which
one"? That discussion could go on for an eternity with everyon
say this is something we should carefully consider for a 2.0 api. I
> know that, for simplicity, many people really like having the underscore
> prefixed attributes mixed in right alongside the document data, but a
> future
> API that separated these could really make things fly.
>
>
DISCLAIMER: This looks long, but reads quickly (I hope). If you are in a
rush,
just check the last 2 sections and see if it sounds interesting.
Hi everybody. I am new to the list, but a big fan of Couch and I have been
working
on something I wanted to share with the group.
My appologies if this
28 matches
Mail list logo
