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.or >> g/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ë >
