UPSERT Parse Error Due to Unique Constraint Mismatch in SQLite

---

Understanding the Conflict Resolution Failure in UPSERT Operations

Issue Overview: UPSERT Fails to Resolve Composite Unique Constraints in RowID Tables

When attempting to execute an INSERT ... ON CONFLICT DO NOTHING statement (UPSERT) in SQLite, users may encounter a parse error stating, "ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint." This error arises under specific conditions involving tables with redundant or overlapping constraints. The problem is particularly counterintuitive because it disappears when the same table is declared as WITHOUT ROWID.

Consider the following scenario:

1. A table is created with an INTEGER PRIMARY KEY column (id), a UNIQUE constraint on a separate column (hash), and a composite UNIQUE constraint on (id, hash).
2. An INSERT statement attempts to handle conflicts on the composite (id, hash) constraint using ON CONFLICT (id, hash) DO NOTHING.
3. SQLite rejects this with a parse error, claiming the conflict target does not match any existing constraint.

However, when the same table is redefined as WITHOUT ROWID, the UPSERT operation succeeds. The discrepancy highlights a critical interaction between SQLite’s internal row identifier system (rowid), constraint validation logic, and UPSERT conflict resolution.

The behavior becomes even more puzzling when observing constraint violations in WITHOUT ROWID tables:

• Inserting duplicate (id, hash) pairs is ignored as intended.
• Inserting conflicting id or hash values separately triggers runtime errors for their respective constraints.
  This demonstrates that SQLite correctly recognizes individual and composite constraints in WITHOUT ROWID tables but fails to do so in standard tables with implicit rowid.

The core issue revolves around SQLite’s inability to resolve the composite (id, hash) constraint as a valid conflict target in tables that use the default rowid structure. This limitation stems from internal optimizations and constraint validation rules that differ between rowid and WITHOUT ROWID table types.

---

Possible Causes: Redundant Constraints and RowID Optimization Conflicts

The root cause of the UPSERT parse error lies in SQLite’s constraint validation logic and its handling of overlapping or redundant constraints. Let’s dissect the contributing factors:

1. Redundant Composite Unique Constraint
   The composite UNIQUE (id, hash) constraint is logically redundant because id is already the PRIMARY KEY. In standard SQLite tables, the PRIMARY KEY is implemented as a UNIQUE index. Adding a composite UNIQUE constraint involving the primary key creates ambiguity for the conflict resolution engine. SQLite prioritizes the PRIMARY KEY constraint and may ignore or misclassify the composite constraint when parsing UPSERT clauses.

2. RowID Optimization and Hidden Index Behavior
   In tables with an INTEGER PRIMARY KEY, SQLite aliases the rowid to the id column. This optimization allows for faster lookups but introduces hidden behavior:

   • The rowid becomes the primary key storage mechanism.
   • Composite UNIQUE constraints are stored as separate indexes, but SQLite’s UPSERT logic may fail to associate them with the conflict target if they overlap with the rowid-aliased column.

3. Conflict Target Validation Logic
   SQLite’s parser enforces strict rules for UPSERT conflict targets:

   • The columns specified in ON CONFLICT (...) must exactly match a UNIQUE index or PRIMARY KEY constraint.
   • In rowid tables, the composite (id, hash) constraint is treated as a secondary index. However, since id is the rowid, SQLite may internally prioritize the PRIMARY KEY index and disregard the composite constraint during conflict resolution.

4. WITHOUT ROWID Table Structural Differences
   Tables declared as WITHOUT ROWID store data directly in the primary key’s B-tree, eliminating the rowid optimization. This structural change forces SQLite to treat all constraints uniformly, including composite ones. The composite (id, hash) constraint becomes a first-class index, allowing the UPSERT clause to recognize it as a valid conflict target.

5. Parser Limitations in Conflict Clause Matching
   The SQLite parser uses a greedy algorithm to match conflict targets to existing constraints. When multiple constraints overlap (e.g., PRIMARY KEY (id) and UNIQUE (id, hash)), the parser may fail to identify the composite constraint as a valid target due to internal indexing priorities.

---

Troubleshooting Steps, Solutions & Fixes: Resolving Constraint Mismatches in UPSERTs

To address the UPSERT parse error and achieve the desired idempotent insert behavior, consider the following solutions:

1. Eliminate Redundant Constraints

Remove the composite UNIQUE (id, hash) constraint if it serves no practical purpose. The PRIMARY KEY (id) and UNIQUE (hash) constraints already enforce uniqueness for their respective columns.

Example:

CREATE TABLE a (
  id INTEGER PRIMARY KEY,
  hash TEXT UNIQUE NOT NULL
);

Pros: Simplifies schema, avoids parser confusion.
Cons: Loses the ability to detect composite (id, hash) conflicts.

2. Use WITHOUT ROWID Tables

Declare the table as WITHOUT ROWID to force SQLite to treat the composite constraint as a primary index.

Example:

CREATE TABLE a (
  id INTEGER PRIMARY KEY,
  hash TEXT UNIQUE NOT NULL,
  UNIQUE (id, hash)
) WITHOUT ROWID;

Pros: Maintains composite constraint recognition in UPSERTs.
Cons: Increases storage overhead; WITHOUT ROWID tables lack rowid optimizations.

3. Use Expression-Based Indexes

Create a unique index using an expression (e.g., +id) to trick SQLite into treating the composite constraint as a separate index.

Example:

CREATE TABLE a (
  id INTEGER PRIMARY KEY,
  hash TEXT UNIQUE NOT NULL
);
CREATE UNIQUE INDEX a_full ON a (+id, hash);

Insert Statement:

INSERT INTO a (id, hash) VALUES (1, 'hash') 
ON CONFLICT (+id, hash) DO NOTHING;

Pros: Avoids schema restructuring.
Cons: Requires non-standard syntax in INSERT statements; expression indexes may have performance implications.

4. Implement Conflict Resolution with Triggers

Use a BEFORE INSERT trigger to manually check for composite constraint violations and ignore duplicates.

Example:

CREATE TABLE a (
  id INTEGER PRIMARY KEY,
  hash TEXT UNIQUE NOT NULL
);

CREATE TRIGGER a_pre BEFORE INSERT ON a
WHEN EXISTS (
  SELECT 1 FROM a 
  WHERE id = NEW.id AND hash = NEW.hash
)
BEGIN
  SELECT RAISE(IGNORE);
END;

Pros: Full control over conflict logic; no parser limitations.
Cons: Adds trigger maintenance overhead; may impact insert performance.

5. Use INSERT OR IGNORE with Separate Constraints

Replace ON CONFLICT with INSERT OR IGNORE and rely on individual constraints to catch errors.

Example:

INSERT OR IGNORE INTO a (id, hash) VALUES (1, 'hash');

Pros: Simplifies syntax.
Cons: Silently ignores all constraint violations, not just composite ones.

6. Schema Redesign: Decouple Composite Constraints

Split the table into two entities to isolate constraint domains.

Example:

CREATE TABLE a (
  id INTEGER PRIMARY KEY,
  hash_id INTEGER NOT NULL,
  FOREIGN KEY (hash_id) REFERENCES hashes(id)
);

CREATE TABLE hashes (
  id INTEGER PRIMARY KEY,
  hash TEXT UNIQUE NOT NULL
);

Pros: Eliminates composite constraint ambiguity.
Cons: Increases schema complexity; requires joins for simple queries.

7. Upgrade SQLite Version

Ensure you’re using the latest SQLite version, as newer releases may address parser limitations.

Example:

$ sqlite3 --version
SQLite version 3.45.0 2024-03-12 11:06:23

Pros: Potential upstream fixes.
Cons: No guarantee of resolution; requires application testing.

---

Final Recommendation:
For most use cases, Solution #2 (WITHOUT ROWID) or Solution #4 (Triggers) provides the best balance between clarity and functionality. If schema simplification is acceptable, Solution #1 eliminates the problem entirely. Avoid Solution #5 if granular conflict handling is required.