Skip to content
This repository has been archived by the owner on Dec 6, 2023. It is now read-only.

Conditional Fetch requests support #39

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

ajantis
Copy link
Collaborator

@ajantis ajantis commented Jul 7, 2016

Overview

Introduces support for conditional request parameters when fetching a value from Riak bucket.

Riak Fetch Object (HTTP API) parameters are described in here:
http://docs.basho.com/riak/kv/2.1.4/developing/api/http/fetch-object/#request

Supported conditions:

  • IfMatch - fetch a value if it has the same ETag.
  • IfNotMatch - fetch a value if it has a different ETag.
  • IfModifiedSince - fetch a value if it has been modified (Last-Modified attribute) since a specific time.
  • IfUnmodifiedSince - fetch a value if it has been modified (Last-Modified attribute) since a specific time.

Conditions can be combined together.

Compatibility

This change is backwards compatible with existing code that uses the library.

Tests

Tested with integration specs (RiakBucketSpec.scala) against Riak 1.4 (1.4.10) and Riak 2 (2.1.1).

Future improvements

Conditional parameters support can be expanded also to Store Object API:
http://docs.basho.com/riak/kv/2.1.4/developing/api/http/store-object/#request

It works the same way in Riak.

Support of other API backends

Note that the conditional requests support in Protobuf API is a bit different:
http://docs.basho.com/riak/kv/2.1.4/developing/api/protocol-buffers/fetch-object/#request

  • No support of conditions based on Last-Modified attribute.
  • If(Not)Match conditions are based on VClocks, not ETags.

So HTTP API and Protobuf API are not on par in that sense.

ajantis added 19 commits July 5, 2016 18:35
…nd If-(Not)-Modified HTTP headers support in Riak
As IfNoneChange accepts only one ETag value it's probably better to adjust it's name accordingly
@coveralls
Copy link

coveralls commented Jul 7, 2016

Coverage Status

Coverage increased (+0.5%) to 81.308% when pulling 11ac7d0 on ajantis:conditional-fetch-support into 54f742a on agemooij:master.

import spray.http.Uri
import spray.http.Uri._
private[riak] trait RiakHttpSupport {
import spray.http.{ Uri, HttpHeader, HttpHeaders, EntityTag }, HttpHeaders._, Uri._
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer consistent wildcard imports instead of explicit imports but that's a personal thing and I'm not religious about it.

@agemooij
Copy link
Owner

agemooij commented Jul 7, 2016

Looks good!
I made some minor comments but nothing really important. Feel free to merge at any time.

// TODO: case NotModified => successful(None)
case OK ⇒ successful(toRiakValue(response))
case NotFound ⇒ successful(None)
case NotModified ⇒ successful(None) // This means that client is not able to distinguish cases when value is not in Riak or a supplied condition is not met.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a way to distinguish between the not-found and not-modified case? Perhaps in a different method to retain backwards compatibility.

@ajantis
Copy link
Collaborator Author

ajantis commented Jul 8, 2016

Hey Age,

Thanks for your swift review! ;)
I am applying the comments.

Didier's remark makes sense, too: I also was thinking that it might be needed for a client to be able to distinguish 'Not Found' and 'Found but Precondition Failed' cases.

BR,
Dmitry

@agemooij
Copy link
Owner

I agree with @didierliauw too.

I recommend using Spray's StatusCodes (or akka-http's StatusCodes) as inspiration since Http doesn't have 404 and 304 for nothing 😄

@ajantis
Copy link
Collaborator Author

ajantis commented Feb 21, 2017

I put this change on hold for now, as there is one substantial piece missing. In case of siblings, all ETag-based conditions don't work with resolved RiakValue's ETag, only with the parent ETag.
Currently, library doesn't expose those parent ETags anyhow, so this needs to be fixed as part of this PR, I guess.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants