Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
sql: ban ON CONFLICT REPLACE for secondary indexes #2963
Consider we have a space with multiple UNIQUE constraints, which have different ON CONFLICT clauses. If there are no constraint with ON CONFLICT REPLACE, then constraints execution order doesn't matter, because uniqueness violation doesn't affect data in a given space. However, when we have secondary index with ON CONFLICT REPLACE, it can bring us to an interesting results. Consider next example:
That is space condition before constraints violation. Pay attention to the fact that PRIMARY KEY error action is ABORT, not REPLACE.
Now try to insert a tuple, which violates:
As you can see, there was a duplicate in primary key index, however, the insertion was successful and as a result, error action was REPLACE for primary key index instead of ABORT, which should happen by definition of that index.
And the root of that problem is that execution of constraint with ON CONFLICT REPLACE happens BEFORE making an insertion into Tarantool, which performs a uniqueness checks for constraints with default error action (ABORT). Also ALL tuple with conflicting key in secondary index will be deleted from space, after that a whole new one will be inserted.
Solution is simple - SQL ON CONFLICT REPLACE semantics should be the same as in Tarantool, where REPLACE is allowed only for primary key index.
added a commit
Nov 30, 2017
added a commit
Dec 26, 2017
There are two possible solutions:
The problem with 2nd approach is that the order of execution also involves execution of Tarantool triggers, which happens after checking all constraints.
So we need to decide which approach we should take into account.