> I don’t understand why you want to atomically append to an array here instead
> of using a separate
> (DbName, Versionstamp) KV each time. What’s the advantage? Both structures
> require periodic
> cleanup. I also don’t understand why you need this DbName -> Versionstamp
> mapping at
Hi Ilya,
I agree it would be quite nice if there was a way to implement this feature
without a background worker — while also avoiding write contention for
transactions that would otherwise not conflict with one another. I’m not sure
it’s possible.
I have a few comments:
> We could maintain
Hi,
Both proposals are fine but need a consumer process. Which is a tricky
requirement because it will lead to problems in cases when queue grows faster
than we can consume it. This realization got me thinking about finding possible
ways to eliminate the need for a consumer.
I wouldn't spell
Looking over the code, it seems very simple and clean. Without knowing much
of the internals or following the discussion too closely I think I was able
to read and understand most of it.
I like split between db and fdb layers. Hopefully it means if we start from
this we can do some parallel work
Hey everyone!
I've gotten enough of a FoundationDB layer prototype implemented [1]
to start sharing publicly. This is emphatically no where near useful
to non-CouchDB-developers. The motivation for this work was to try and
get enough of a basic prototype written so that we can all start
fleshing
A tested pull request that does the right thing and keeps the same uid/gid we
currently use would be welcomed and considered seriously.