Conflict resolution strategy

[FabioBatSilva]

In order to make the API easier to use would be nice to have conflict resolution strategies..

• Add attribute Riak\Input\PutInput#conflictResolver
• Add attribute Riak\Bucket#conflictResolver
• Add method Riak\Output\Output#getObject()
• Add interface Riak\Output\Resolver\ConflictResolver
• Add exception Riak\NonUniqueException
• Add exception Riak\UnresolvedConflictException

API Changes :

<?php

namespace Riak\Output;

class PutOutput 
{
    // ...
    /** 
    * Retrieves a unique riak object
    * 
    * If this output contain more than one object 
    * it will try to resolve its siblings using a ConflictResolver specified by PutInput or Bucket
    * 
    * if there are no ConflictResolver configured for its Bucket nor PutInput it will throws a NonUniqueException
    * otherwise the ConflictResolver will be responsible for resolving the siblings into a single object.
    *
    * @return \Riak\Object
    *
    * @throws \Riak\NotFoundException   If this output contain none objects
    * @throws \Riak\NonUniqueException  If this output contain more than one object
    * @throws \Riak\UnresolvedConflictException If the ConflictResolver cannot determine a single object.
    */
    public function getObject(){}
}

namespace Riak\Output\Resolver;

interface ConflictResolver 
{
    /** 
    * Applies encoded logic to produce a single value from a list of siblings.
    *
    * @param \Riak\Bucket              $bucket
    * @param \Riak\Output\Output       $output
    * @param \Riak\Input\PutInput|null $putInput
    *
    * @return \Riak\Object
    *
    * @throws \Riak\UnresolvedConflictException If it cannot determine a single value.
    */
    public function resolve(Bucket $bucket, Output $output, PutInput $putInput = null);
}

Some basic built-in conflict resolver

• FirstSiblingResolver - Resolve the conflict using the first object in Output#objectlist
• LastSiblingResolver - Resolve the conflict using the last object in Output#objectlist

API Usage :

Manually resolving siblings

<?php
$props  = new \Riak\BucketPropertyList($nVal = 3, $allowMult = true);
$bucket = new \Riak\Bucket($client, 'test_bucket');
$output = null;

try {
    $output = $bucket->get($key);
    $object = $output->getObject();
} catch (\Riak\NotFoundException $e) {
    // Not found 
} catch (\Riak\NonUniqueException $e) {
    $winner   = doSomeMagicAndResolveTheWinner();
    $options  = new \Riak\Input\PutInput();

    $options->setVClock($output->getVClock());
    $bucket->put($winner, $options);

    $output = $winner;
}

Auto resolving sibling using the last object

<?php
$props   = new \Riak\BucketPropertyList($nVal = 3, $allowMult = true);
$bucket  = new \Riak\Bucket($client, 'test_bucket');

// Configure a default resolver
$props->setConflictResolver(new LastSiblingResolver());
$bucket->setPropertyList($props);

$output = $bucket->get($key);
// this $output contain more than one object
echo $output->hasSiblings(); 
// Resolve the conflict using the LastSiblingResolver
$object = $output->getObject();

Auto resolving a specific key using a custom ConflictResolver

<?php

class MyResolver implements ConflictResolver
{
    /**
     * {@inheritdoc}
     */
    public function resolve(Bucket $bucket, Output $output, PutInput $putInput = null) 
    {
         $winner   = doSomeMagicAndResolveTheWinner();
         $options  = new \Riak\Input\PutInput();

         $options->setVClock($output->getVClock());
         $bucket->put($winner, $options);

         return $winner;
    }
}

$props   = new \Riak\BucketPropertyList($nVal = 3, $allowMult = true);
$options = \Riak\Input\GetInput();

// Configure a resolver for a specific get operation
$options->setConflictResolver(new MyResolver());
$bucket->setPropertyList($props);

$output = $bucket->get($key, $options);
// this $output contain more than one object
echo $output->hasSiblings(); 
// Resolve the conflict using MyResolver
$object = $output->getObject();

If you guys agree with this approach I'll be happy to prepare a PR ;)

PS: We could probably use a similar approach to handle retry policies during get/put operations..

Cheers ..

[bachpedersen]

I do think it is a good idea, and I like the solution (with a few tweaks), but I am a bit conflicted about putting it in the driver though, what is your thought about doing it as a php addon package instead the more C code the more pain ;)

[FabioBatSilva]

Doing this as a php package would be easier but introduces another dependence..
IMO this is a very common operation, almost every one using Riak need to implement some kind on conflict resolution..

Having this as part of the driver, makes a lot easier to implement reusable conflict resolution without any external dependency.

[bachpedersen]

You are right, and it could go in the driver if you have the time to do it? I am a bit "burnt out" of C love atm. :(
About the implementation suggested above I have some suggestion below that I hope improves.

Here is my take on the interface:

I do not think the implementer should be responsible for the the actual put, php_riak should handle that automatically as long as you supplied a conflictresolver.
The problem is now that when the get function detects siblings and it calls the conflictresolver and get the final object back it does not know which PutInput that should be used when storing back (which is why i added the ResolveInput futher down).

Here is my suggestion for changes to the resolver interface:

use Riak\ObjectList;
interface ConflictResolver {
/**
* Resolve or merge the conflicting objects and return one that should be store back into riak.
* @param ObjectList $objects
* @return Object|null
*/
public function resolve(ObjectList $objects);
}

imo. we should only add the conflict resolver to the GetInput as conflicts are almost always resolved when you do get operations (it is possible to resolve conflicts on put, if return body is set true, but I do not think this is a common pattern)
I do not like setting a resolver on bucket object as this does not fit it with the single responsibility design and it can add some confusion for users when buckets are passed around.

GetInput could be extended like this
/**
* @param ResolveInput $resolveInput
*/
public function setResolveInput(ResolveInput $resolveInput) {}

And the resolveInput could look like this
use Riak\Input\PutInput;

class ResolveInput
{
public function __construct(ConflictResolver $resolver) {}

public function setMaxNumberOfResolveTries($max) {}

/**
 * @param ConflictResolver $resolver
 * @return ResolveInput
 */
public function setResolver(ConflictResolver $resolver) {}

/**
 * @param PutInput $putInput
 * @return ResolveInput
 */
public function setPutInput(PutInput $putInput) {}

}

This make the use very simple and the changes to API is pretty limited, it might need a couple of more lines of code though.

In the php_riak get function in the code it would then have to check for siblings and call the resolve and put and possible pass on exceptions etc.

What is your though on the changes above?

btw. I killed the NotFoundException a couple of releases a go as it is a common "non error".

[FabioBatSilva]

Cool..

I'm working on a patch,
Once I get it working i'll send you a pull request..

[bachpedersen]

Merged, nice work!

[bachpedersen]

Is it ok if i kill the LastResolver and rename the First to Youngest (and expand it a bit)?

[FabioBatSilva]

What about LatestSiblingResolver and YoungestSiblingResolver ?

[bachpedersen]

You mean the oldest? I don't see any use where you would want the oldest to win., but Latest is probably a better name than Youngest.
(but tbh. there is very few reasons you would use a resolver that just takes one, since it is better to just set allowMult false on bucket)

[guilhermeblanco]

OldestSiblingResolver and YoungestSiblingResolverare my votes.
A default implementation on both would not hurt, specially if you have different sections that may use one algorithm and other that uses the other (making allowMult bucket property not an option). =\

[bachpedersen]

Tbh. you should use different buckets with different properties, Riak will do a better job of keeping track of what went in last if you use allowMult=false and lastWriteWins=false and ignored resolvers all together.
The YoungestSiblingResolver I can se some use for, eg. if you haven't implemented the real resolver yet you can use YoungestSiblingResolver untill your merge function is done.

On the downside, having a YoungestSiblingResolver might lead people to use that instead of using Riak with lww=false and allowMult=false, which will do better job.

Anyways YoungestSiblingResolver will be there for sure, but is there any real use for an Oldest resolver? what would you use it for.