Do we publish a CouchDB+Clouseau docker?
Hi there, Recently IBM donated their CouchDB+Clouseau (in RedHat UBI form) docker container to the apache/couchdb-docker repository. One of their customers, Grapevine AI, is asking if we can release this and publish it under the apache/couchdb Docker Hub location. As I said in the merge request here : https://github.com/apache/couchdb-docker/pull/187 We haven't had the time to review any licensing and operational considerations to publish this image. Previously, licensing considerations around Java and the runtime were the main reason we didn't ship this in our binary downloads. Docker is a little different in that we're only putting together a recipe, and a 3rd party builds the binaries, but it deserves discussion. Given that Cloudant haven't donated the Clouseau code to Apache, and it's my understanding that this code isn't likely to be maintained going forward beyond bare-minimum effort to keep it running, I'm reluctant to slap the Apache name on it and mark this a supported image from our perspective - though it's been stable for a while. Perhaps @rnewson can comment further here, as the main progenitor of the code in question. I will bring this up on our development mailing list, where the decision needs to be made. Of course, nothing's stopping you from building and publishing the image yourself for your own needs today. Keep in mind you may not label it as "Apache CouchDB" or advertise it as such, as this is trademarked by the Foundation and under our control. I'd like to see what the (binding, voting) committers think about this issue before acting, as I can't decide simply what's in the best interest of the project on this one. Please speak up. -Joan "groggy" Touzet
Re: object keys in couchdb 4
San,
I don't remember that being a performance issue under consideration
for the "exploded document" design that we had contemplated in
particular, but I could see there being some concerns around it.
However, we have not implemented that idea and instead just store
documents in as few consecutive keys as possible so in terms of fdb,
the doc bodies are just a string of bytes so its definitely a
non-issue with the current design.
Paul
On Tue, Jul 28, 2020 at 4:15 PM San Sato wrote:
>
> During the design process with FDB integration, there was talk about issues
> with nesting keys having user-provided values, the gist of which was, as I
> recall, was that having many documents *{ _id: "xyz", o: ...}* with *o*'s
> value being a nested object with runtime-generated, non-predictable keys *{x1,
> x2, y1, y2, y3, m1...mX, n, ...}* harms FDB performance; that FDB keyspace
> prefers, operationally, to be relatively static (maybe this had something
> to do with joined paths-to-value, and limiting the number of distincts in
> the flattened namespace for the keys?).
>
> Is that still the case?
>
> Thanks,
object keys in couchdb 4
During the design process with FDB integration, there was talk about issues
with nesting keys having user-provided values, the gist of which was, as I
recall, was that having many documents *{ _id: "xyz", o: ...}* with *o*'s
value being a nested object with runtime-generated, non-predictable keys *{x1,
x2, y1, y2, y3, m1...mX, n, ...}* harms FDB performance; that FDB keyspace
prefers, operationally, to be relatively static (maybe this had something
to do with joined paths-to-value, and limiting the number of distincts in
the flattened namespace for the keys?).
Is that still the case?
Thanks,
