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.
Message -
> From: "Adam Kocoloski"
> To: dev@couchdb.apache.org
> Sent: Thursday, February 28, 2019 6:41:15 AM
> Subject: Re: [DISCUSS] Attachment support in CouchDB with FDB
>
> I would like to see a basic “native” attachment provider with the
> limitations describ
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
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
