I'm sorry I cannot disclose all the details but essentially for this bucket it's enough to check if a specific item is already present or not. All the information identifying the item is part of the key so there is no need to have anything in the body.
A generic example could be a discount voucher system where the voucher id is unique. As soon as the voucher has been used a new item is created in the bucket *used-vouchers* and every time the system needs to validate a voucher, then it's enough to check if that id already exists in the bucket. Who really used the voucher can be part of another bucket (named orders maybe?) and associated with a secondary index to the voucher, with slower performances compared to key lookup. Does it make sense? Vincenzo On Wed, Sep 11, 2013 at 4:22 AM, Sam Elliott <sam.elli...@basho.com> wrote: > I'm interested to know why you're trying to store an empty body in Riak. > Surely just don't even make the request to Riak? I guess I could be > overlooking something obvious. > > Sam > -- > Sam Elliott > Engineer > sam.elli...@basho.com > -- > > > On Tuesday, 10 September 2013 at 6:29PM, Vincenzo Vitale wrote: > > > Hi Sam, > > thanks for the fast reply. > > > > In my company we normally use your third suggestion and indeed it's a > robust strategy. > > > > At the moment we are relying on a riak client based on spray ( > https://github.com/agemooij/riak-scala-client) so even if we set the > Content-Type - when the body is empty - it doesn't get to the final request > being dispatched. > > > > Our workaround is to have a content body equal to the one byte carriage > return. > > It's not a big deal... > > > > Writing to the mailing list was mainly because curious to know your > thoughts about this :) > > > > > > Have a good day, > > V. > > > > > > > > On Wed, Sep 11, 2013 at 12:03 AM, Sam Elliott <sam.elli...@basho.com(mailto: > sam.elli...@basho.com)> wrote: > > > The content-type is important for Riak KV: Various clients will use it > to identify the difference between a response where the whole body is the > key, or a response that contains siblings (if you have allow_mult=true). > > > > > > I suggest finding or creating a content type, so that this is clearer > to your app. It will also allow you to version your objects better. Here > are a few suggestions (of course replace the text between the < >): > > > - application/octet-stream - this is usually used for binary data, and > is the easiest thing to set the content-type to. > > > - application/vnd.<company name>.<useful type name here> - a > vendor-specific type, which you can create yourself > > > - application/vnd.<company name>.<useful type name here>.v<version > number> - another vendor-specific type, which supports versioning. > > > > > > You don't have to use the information in your final app, but it is > used by riak and riak clients, so that's why we require it. > > > > > > -- > > > Sam Elliott > > > Engineer > > > sam.elli...@basho.com (mailto:sam.elli...@basho.com) > > > -- > > > > > > > > > On Tuesday, 10 September 2013 at 5:03PM, Vincenzo Vitale wrote: > > > > > > > Suppose I want to just store keys in a bucket without any body, this > make sense in scenarios where the key completely identify the entity. Is it > possible to use the riak http api without including the content-type header? > > > > Looking at the http specifications, content–type is not mandatory or > suggested when the body is empty: > > > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 > > > > and it's probably a good argument to say that if the entity message > is empty then the content type doesn't really make sense. > > > > Personally I think that just the existence of an http entity - body > or not body – is sufficient to justify a "type"; it's unfortunate that any > other higher type (entity type maybe?) - decoupled from what is defined as > content - exist in the spec. > > > > Framework like spray are quite strict about this, not setting any > content type when the content is empty: > > > > > https://github.com/spray/spray/blob/master/spray-http/src/main/scala/spray/http/HttpEntity.scala#L74 > > > > how to deal with such situation? Adding a fake content because of > this data store constraint doesn't seems right. > > > > > > > > > > > > Thanks, > > > > Vincenzo. > > > > > > > > -- > > > > If your e-mail inbox is out of control, check out > http://sanebox.com/t/mmzve. I love it. > > > > _______________________________________________ > > > > riak-users mailing list > > > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > (mailto:riak-users@lists.basho.com) > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > > > > > > -- > > If your e-mail inbox is out of control, check out > http://sanebox.com/t/mmzve. I love it. > > > > -- If your e-mail inbox is out of control, check out http://sanebox.com/t/mmzve. I love it.
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
