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

Reply via email to