I’ve gone ahead and submitted an RFC for the design discussed here with a small
modification:
https://github.com/apache/couchdb/issues/1957
Cheers, Adam
> On Feb 11, 2019, at 2:37 PM, Adam Kocoloski wrote:
>
> Agreed, I don’t have answer for this. I propose to drop the optimization for
>
On Thu, 28 Feb 2019, at 13:19, Robert Newson wrote
> Thanks to you both, and I agree.
>
> Adam's "I would like to see a basic “native” attachment provider with
> the limitations described in 2), as well as an “object store” provider
> targeting the S3 API." is my position/preference too.
Chiming in to agree with option 2, and if that's too small for
you, you should be able to use either an cloud backend, or a
local file system approach.
Cloud backend should be abstracted to the point where you could
build support for something other than S3 - for instance, B2[1]
would be lovely -
Thanks to you both, and I agree.
Adam's "I would like to see a basic “native” attachment provider with the
limitations described in 2), as well as an “object store” provider targeting
the S3 API." is my position/preference too.
--
Robert Samuel Newson
rnew...@apache.org
On Thu, 28 Feb
I would like to see a basic “native” attachment provider with the limitations
described in 2), as well as an “object store” provider targeting the S3 API. I
think the consistency considerations are tractable if you’re comfortable with
the possibility that attachments could possibly be orphaned
Hi,
Yes, I agree we should have a framework like that. Folks should be able to
choose S3 or COS (IBM), etc.
I am personally on the hook for the implementation for CouchDB and for IBM
Cloudant and expect them to be different, so the framework, IMO, is a given.
B.
> On 28 Feb 2019, at
Hanks Adam and Robert for sorting this one.
Michael, the idea is to give mutually untrusting users access a
as-close-to-verbatim-CouchDB API to their section of a shared database. So you
get full doc CRUD, _changes, views, replication, the lot, but only for
documents that you have access to.
Thanks for getting this started, Bob!
In fear of derailing this right off the bat, is there a potential 4) approach
where on the CouchDB side there is a way to specify “attachment backends”, one
of which could be 2), but others could be “node local file storage”*, others
could be S3-API
Hi All,
We've not yet discussed attachments in terms of the foundationdb work so here's
where we do that.
Today, CouchDB allows you to store large binary values, stored as a series of
much smaller chunks. These "attachments" cannot be indexed, they can only be
sent and received (you can fetch
