If it isn't a counter type, then why calculate the diff value, just do the insert.
On Tue, Nov 5, 2013 at 2:28 PM, Luiz Carlos Jr <l...@s1mbi0se.com.br> wrote: > Hi Christopher, > > Actually it's not a counter, but just a field that stores integers. I'm > logging the expected values but not the command itself because I'm using > pycassa to send it. I'm absolutely sure that it's not an overflow case. I'm > talking about numbers in order of 10~100k with no math operators that could > raise an expection (only one subtraction operation). > > Any other ideas ? Thanks for the tips ! > > > On Tue, Nov 5, 2013 at 12:29 PM, Christopher Smith <cbsm...@gmail.com > >wrote: > > > Given your use case I'd recommend not using a counter for the field. > > > > Are you logging the update command you are sending Cassandra? Are you > sure > > you aren't overflowing the value either in Cassandra or in your batch > code? > > > > On Monday, November 4, 2013, Luiz Carlos Jr wrote: > > > > > Hi ! > > > > > > I have a script written in python that should update a counter in > > > Cassandra. It acts like a batch that corrects the counter. > > > > > > What script does is: get the real value that should be at database, get > > the > > > current value that is persisted at database, calculates the difference > > > between values and finally send insert command to specific row key > > passing > > > the diff to update the counter. > > > > > > All works fine. I got the correct values and diffs but, after insert > > > command, the value of row key is not the expected. > > > > > > Example: > > > Real Value = 35000 > > > Current DB Value = 30000 > > > Diff Value = 5000 > > > > > > I sent the insert command passing diff=5000 so, the expected new DB > value > > > should be 35000. But sometimes the new DB value is a crazy negative > > number, > > > like -360.000. It doesn't make any sense, because there's no > combination > > of > > > values and operators that could result on a value like that. > > > > > > And, if i run the script again, the final persisted value is correct. > If > > I > > > try again later the final persisted value appears wrong again... > > > > > > Can anyone help me with this ? The same script sometimes works fine and > > > sometimes persists a crazy value. > > > > > > Thank you ! > > > > > > > > > -- > > Chris > > > -- Chris