Jiak issue

Bryan Fink bryan at basho.com
Fri Nov 13 15:34:43 EST 2009

On Thu, Nov 12, 2009 at 10:57 AM, Bryan Fink <bryan at basho.com> wrote:
> On Thu, Nov 12, 2009 at 10:39 AM, Paul Rogers <riak at dingosky.com> wrote:
>> I've run into what is either a Jiak bug or a bug in my expectation. I've
>> outlined summary and detail steps to reproduce.
>> Step 1
>>  Add data under full or wildcard schema
>>  e.g. JSON with fields f1, f2, and f3
>> Step 2
>>  Restrict write_mask
>>  e.g. Restrict write mask to just f1 and f3
>> Step 3
>>  Update previous data, sending only write_mask fields
>>  e.g. Update with only JSON fields f1 and f3
>> Issue
>>  Jiak exception due to write mask violation
>>  e.g. Error message notes f2 cannot be written, even though f2 was not in
>>  the JSON payload in the Step 3 update.
>> Note
>>  In Step 3, it is allowable to send new data with only the f1,f3 fields, and
>>  even update that data. Only prior existing data causes the issue.
> ...snip...
>> Looks to me that somewhere in either Jiak or Riak the f2 field of the
>> existing data is being read and written and that's being flagged as a
>> write_mask violation.
> Hi, Paul.  Leaving the f2 field out of your update is seen as changing
> f2 to undefined, not as leaving f2 unchanged.  You can leave f2 out of
> a new object because its value was undefined to begin with (so it's
> not a change/write in that case).
> -Bryan

A slight update here: There was actually a bug in Jiak around
"unreadable" fields.  If an object was stored in Riak with a value for
a field that was not in the read_mask, and if a PUT came in for that
object including a value for that field, which happened to be the same
value already stored, the PUT would succeed, but create an object in
Riak that had multiple values for the field.  These multiple values
would cause later requests to fail, regardless of whether or not they
contained values for the unreadable field.

That is:

A bucket with read_mask=write_mask=[a], allowed=*, required=[]

An object with {a=1,b=1}

PUT {a=2,b=1}

Would create an object in Riak like {b=1,a=2,b=1} (note the duplicated b value)

Latest modification requests against this object would fail due to the
conflict between this format and the expectations of the schema

I've just pushed a fix for this bug.  The fix changes the logic around
copying unreadable fields from "just copy them" to "copy them only if
the client didn't include a value for them."


More information about the riak-users mailing list