Closed GoogleCodeExporter closed 8 years ago
All memcached binary packets contain a cas field and can therefore take a cas
value. Below is a link to the source code that shows cas being processed by an
append. If this wasn't clear in the documentation then could you propose hat
should be added to make it better.
https://github.com/memcached/memcached/blob/master/memcached.c#L850
Original comment by mikewie...@gmail.com
on 30 Nov 2011 at 4:21
The underlying binary packets always contain the cas field, but the cas field
is always zero. the behavior of server when you set cas in append() is
undefined.
I propose add a new append() which has no cas parameter, and deprecated the
origin append() method.
Original comment by pop.atry@gmail.com
on 30 Nov 2011 at 4:59
I still disagree with you here and you may take a look at the source code if
you like. Also, I just looked over the documentation you linked to and I
couldn't find anything that says that the cas must always be zero.
Also, I pointed you to the wrong function above (ascii instead of binary).
If you look here you will see that the append function is being processed
https://github.com/memcached/memcached/blob/master/memcached.c#L2174
Then in that function (process_bin_append_prepend) you can see that at the
bottom the substate is set to bin_read_set_value. If you go back to the link
above you will see that this state is right below the one that caused us to go
to the process_bin_append_prepend function in the switch-case statement. If you
go to the function that is called from that case statement you will see that
this is the same function that all "store" operations go to. In that function
there is a another function that is called named store_item and this function
will actually check the new and old cas value.
Original comment by mikewie...@gmail.com
on 30 Nov 2011 at 6:07
Original issue reported on code.google.com by
pop.atry@gmail.com
on 30 Nov 2011 at 3:27