Hi, maybe I am wrong here, but from looking at the code of riak_kv_multi_backend I get the impression that the backend name can be anything (binary, atom, integer, ...), as long as it is the same in the multi_backend config and the 'backend' property of the bucket.
The limitation to binaries comes from the REST interface, right? If the bucket properties are set via the native Erlang client one can still use atoms, which should be (slightly) faster. Of course, people who only use the REST interface don't care too much about performance, so the small performance hit of using binaries for the backend name might not matter. Cheers, Nico Am Montag, den 24.01.2011, 16:11 -0800 schrieb Anthony Molinaro: > On Mon, Jan 24, 2011 at 02:15:37PM -0500, Sean Cribbs wrote: > > Default bucket properties are defined in riak_core, not riak_kv, so you > > can't really set the hash function as a result of setting something else. > > Furthermore, you really only have to set these once, so you could configure > > your application to check the bucket props on startup and set them > > appropriately. > > Do you mean in the start/2 of the custom backend, or somewhere else? I > thought > the start/2 function was passed the partition number (which in turn I thought > was a result of calling the hash), but that's just conjecture as I've not had > a chance to trace through the code. If that is the case it seems like it > would > be too late, if you are talking about my application talking to riak, I > thought > there was no way via the pb client to set these options. I'd like to avoid > using a mix of pb and HTTP in my application as it just seems to complicate > things. I'll probably just use curl when I first set things up for now, but > figured I'd put these issues out there in case others have these problems > or the basho developers are bored and looking for things to do ;) > > > "backend" is a property only used by the multi_backend (which isn't used > > that frequently), so it seems a little presumptuous to special-case that > > property (turning it into an atom). There are a few other technical > > reasons that you don't want to arbitrarily turn binaries into atoms. I > > agree that it's not especially intuitive but I think it's a small point of > > pain, especially if we fix the documentation. > > Oh, I assumed since the documentation said atom it was meant to be that, and > most other parameters are either strings, integers or atoms. So binaries are > a bit surprising. But I don't have a strong opinion, so I'll just document > what's working. > > -Anthony > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
