Yes, that's correct, but I don't see any reason you should make things harder on yourself. The overhead of a few binaries is not significant enough to weigh down operations.
Sean Cribbs <s...@basho.com> Developer Advocate Basho Technologies, Inc. http://basho.com/ On Jan 25, 2011, at 5:08 AM, Nico Meyer wrote: > 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 > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
