Move item_id_by_key into a collection field in item table? (Would probably be a “better” C* data model anyway.)
On Tue, 25 Oct 2016 at 16:08 Mickael Delanoë <delanoe...@gmail.com> wrote: > Ok, I understand, thanks. > So now i would like to know if there is some best practices to do what i > want. > I.e inserting entries in several tables (with same partition key) only if > there is not already an entry in the main table. > > Keep in mind i wanted to do that inside a single batch because I can have > 2 concurrent request trying to insert something different but with the same > primary key in the main table. > > If i split the batch in 2 requests(1 with the LWT, 1 with the rest), how > can i ensure the last batch won't override the previous data and that the > whole data will be saved (in case of a problem between request1 and > request2) ? > > Le 24 oct. 2016 12:47, "DuyHai Doan" <doanduy...@gmail.com> a écrit : > > > > "So I guess in that case the Paxos operation does not span multiple table > but operates only the table that has the condition. Am I wrong?" > > --> The fact that you're using a BATCH with LWT means that either ALL > statements succeed or NONE. And to guarantee this, Paxos ballot must cover > all statements. In your case since they span on multiple tables it's not > possible > > On Mon, Oct 24, 2016 at 11:34 AM, Mickael Delanoë <delanoe...@gmail.com> > wrote: > > Thanks DuyHai for the info. > I already see this JIRA, however the use case I describe is slightly > different from the JIRA as there is only ONE condition on ONE table. Other > statements of the batch does not have any condition. > So I guess in that case the Paxos operation does not span multiple table > but operates only the table that has the condition. Am I wrong? > > > > 2016-10-24 10:21 GMT+02:00 DuyHai Doan <doanduy...@gmail.com>: > > As far as I remember, there is an optimization in Cassandra to manage > Paxos ballot per table. So asking a Paxos operation to span multiple tables > (even if same partition key) would require a lot of changes in the current > impl. > > The question has already been raised, you may want to convince the > committers by adding some comments here: > https://issues.apache.org/jira/browse/CASSANDRA-10085 > > On Mon, Oct 24, 2016 at 9:58 AM, Mickael Delanoë <delanoe...@gmail.com> > wrote: > > Hi, > > I would like to use lightweight transaction inside a batch but the request > is rejected by cassandra, however I think this is a use case than could be > handled without problem. > Below is what I wanted to do. > > I am using cassandra 3.7. > > CREATE KEYSPACE test_ksp WITH replication = {'class': 'SimpleStrategy', > 'replication_factor': '1'}; > > CREATE TABLE test_ksp.item ( > user_id bigint, > item_id text, > item_value text, > item_key1 text, > item_key2 text, > PRIMARY KEY ((user_id), item_id)); > > CREATE TABLE test_ksp.item_id_by_key ( > user_id bigint, > item_key text, > item_id text, > PRIMARY KEY ((user_id), item_key)); > > USE test_ksp; > > BEGIN BATCH > INSERT INTO item (user_id, item_id, item_value, item_key1, item_key2) > values (1,'i11','item-C', 'key-XYZ-123', 'key-ABC-789') IF NOT EXISTS; > INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1, > 'key-XYZ-123', 'i11'); > INSERT INTO item_id_by_key (user_id, item_key, item_id) VALUES (1, > 'key-ABC-789', 'i11'); > APPLY BATCH; > > > So as you can see this is a batch that targets 2 tables but with the same > partition key (i.e the same target nodes). Moreover It uses only ONE > condition on one table only. > I don't understand why cassandra returns an error "Batch with conditions > cannot span multiple tables" in that case. > > I understand that if I had used several conditions on different tables it > could be a problem, but in my case there is only one condition and moreover > I have always the same partition key for every table inside the batch. > As there is only one condition, I expected the paxos protocol just act on > this condition and as the partition keys are all the same, the paxos > protocol has only to work with the same replica nodes (not span across > multiple partition). > In my point of view this is as if the LWT was in a single statement, > except that after the LWT is accepted a complete batch has to be executed. > > Is there someone that could explain why this use case need to be rejected > by cassandra? And do you think this is something that cassandra could > handle in a future version ? > > Regards, > Mickaël > > > > > > -- > Mickaël Delanoë > > > >
