On 24 Nov 2017, at 16:45, Jan Lehnardt <[email protected]> wrote:
>
> Hi Mike,
>
> this is a great proposal, thanks a lot! I like this general idea, I guess
> this was what Adam was hinting at in the _access draft review ;)
Heh. But good to see the positive reaction!
> I left one comments inline.
>
>> From this, our proposed API is, which should also help clarify a bit how
>> things work:
>>
>> • Enable shard keys using database create: `PUT /db?use_shard_key=true`.
>> Default false.
>
> Since this is the first of “different kind of database”, we should think
> about how to do this more generally, as I expect more of these options to
> come soon as well, _access comes to mind. Would this then be e.g.: `PUT
> /db?use_shard_keys=true&per_doc_access=true`? It might make sense to put a
> little bit of thought into how to name these options and how to
> enable/disable them. This is a total bikeshed (although one CouchDB is famous
> for), this won’t block this overall proposal, there will be a way to
> enable/disable this, and how exactly is TBD.
I pondered this too. Internally, I originally wondered about there being a PUT
body, like `{shard_key: true, q: 8, per_doc_authz: true}`. I think I've lost
the reasoning someone put forward for not going that way :(
As for naming, I guess one could view them as "flags" and have either
`flag_shard_key=true, flag_per_doc_authz=true` or `flags=[shard_key,
per_doc_authz]`.
The PUT-with-body method is obviously the most extensible (you can easily have
n, q etc. in there too and also non-true/false flag-like values).
Totally happy to see any votes there :)
Mike.
