Hi, I think LWT feature is introduced for your kind of usecases only - you don't want other requests to be updating the same data at the same time using Paxos algo(2 Phase commit). So, IMO your usecase makes perfect sense to use LWT to avoid concurrent updates.
If your issue is not the concurrent update one then IMHO you may want to split this in two steps: - get the transcation_type with quorum factor (or higher consistency level) - And conditionally update the row with with quorum factor (or higher consistency level) But remember, this wont be atomic in nature and wont solve the concurrent update issue if you have. Regards, Rajesh On Wed, Jun 20, 2018 at 2:59 AM, manuj singh <s.manuj...@gmail.com> wrote: > Hi all, > we have a use case where we need to update frequently our rows. Now in > order to do so and so that we dont override updates we have to resort to > lightweight transactions. > Since lightweight is expensive(could be 4 times as expensive as normal > insert) , how do we model around it. > > e.g i have a table where > > CREATE TABLE multirow ( > > id text, > > time text, > > transcation_type text, > > status text, > > PRIMARY KEY (id, time) > > ) > > > So lets say we update status column multiple times. So first time we > update we also have to make sure that the transaction exists otherwise > normal update will insert it and then the original insert comes in and it > will override the update. > > So in order to fix that we need to use light weight transactions. > > > Is there another way i can model this so that we can avoid the lightweight > transactions. > > > > Thanks > > >
