Correcting ordinary insert statement for tables with composite primary keys #1468

trueqbit · 2025-11-27T21:31:23Z

Improvements:

Objects mapped to tables with composite primary keys are now insertable with an ordinary insert statement: they get inserted with the values of the specified object except for default values.
- This improvement contains a bug fix for insert statements into tables without rowid where providing values for primary key columns is required (and expected).

Other improvements:

Validate base table definition when calling make_table().
- Specifically this ensures that only one primary key definition is specified.
- It also means that we can get rid of a runtime error when serializing a get query statement.
Validate column definition with respect to auto-increment specifier on a column primary key and the field type.
Improved documentation as a comment on the ordinary 'insert' statement into tables, describing how the routine behaves with rowid vs. without rowid tables and with a single-column primary key vs. composite keys.
Many more unit tests of course.

Fixes

Corrected some SQLite version test that enable version-dependent SQLite features.

The if-condition used for filtering primary key columns must be the same at run-time as at compile-time.

... to the mapped object type, avoiding hard to read error messages later.

…vailing style

Up until this commit, the functions were referred to as "composite PK functions", although this actually always meant "table PK functions", regardless of whether they were single or composite primary keys defined at the table level.

…olumn

* Improved understanding through legibility.

For proper type safety `storage_t<>::insert()` needs to return an `sqlite3_int64` instead of an `int`. This is the best way to correct the problem. Usually, compilers just accept narrowing type conversions, the nicest thing that can happen is a warning message, the worst is an error depending on compiler flags. The programmer has to handle the rest and it is the best thing to do anyway.

* Check column definition up front when making the column. * Renamed internal traits. * Removed unit test file `is_column_with_insertable_primary_key.cpp`. It became superfluous during the course of development in the past years. Column constraints are checked elsewhere already, and it is now only a duplicate of `is_primary_key_insertable.cpp`.

SQLite documentation clearly states that an auto-incrementable primary key column must be a 64-bit signed integer type.

This approach keeps the previous way if all composite primary key columns have a default value, yet still enables inserting records if the table has composite primary key columns with only some or no default values.

* WITHOUT ROWID is only available since SQLite 3.8.2. * FTS5: consider that it can be explicitly enabled with `SQLITE_ORM_ENABLE_FTS5`. * Auxiliary virtual table columns are only available since SQLite 3.24.0. * Hidden virtual table columns have no version attached.

…type

Only types that can represent a 64-bit signed integer - either integral or custom types - have the required properties to be an alias for the rowid and can cover the whole value range of it.

dev/schema/column.h

dev/schema/table.h

dev/storage.h

examples/except_intersection.cpp

tests/prepared_statement_tests/replace_range.cpp

tests/tests5.cpp

Removes the deprecation notice for using non-64-bit integral types as rowid aliases, deferring the type size integrity to the programmer. There are valid concerns that deprecating integral types with less precision than `sqlite3_int64` will provoke situations where people will start complaining about many compiler warnings. Note: I have retained the partial template specializations for validating integral types for better understanding.

There are valid concerns that deprecating integral types with less precision than `sqlite3_int64` will lead to people complaining about many warnings. As the ordinary insert routine is considered a bit like 'legacy' and is subject to multi-threading issues as well the decision is to implement another object insertion routine in the future and just leave things as they are.

dev/storage.h

fnc12 · 2025-12-08T18:58:00Z

dev/storage.h

+                    using without_rowid = typename table_type::is_without_rowid;
+
+                    table.template for_each_column_excluding<  ///
+                        mpl::disjunction<


nit: probably this could be more readable with local aliases like

using mpl_or = mpl::disjunction; using mpl_and = mpl::conjunction; using mpl_not = mpl::not_;

Well, if this is a serious wish, then we should flatten the namespaces and just define everything in terms of mpl_ prefixes...

it is not so serious wish, it is just a nit, cause you're more familiar with mpl part of the lib

Fixed handling composite primary key columns for tables without rowid

10ce490

The if-condition used for filtering primary key columns must be the same at run-time as at compile-time.

trueqbit linked an issue Nov 27, 2025 that may be closed by this pull request

False NOT NULL constraint failure for table with true composite primary key #1467

Closed

trueqbit added 15 commits November 28, 2025 17:36

Unit tests for insertions into tables without rowid and compound PKs

0706a7b

Check up front whether type of range to insert or replace is convertible

64bfce4

... to the mapped object type, avoiding hard to read error messages later.

Removed the period after static assert messages, according to the pre…

f1f81fa

…vailing style

Unit test for serializing for insert statements involving a primary key

871b134

Moved cpp guard that enables testing projected range insertions

dac555b

Same compiler warning options for GNU as for Clang for unit tests

9d93093

Renamed functions dealing with the table primary key

df79495

Up until this commit, the functions were referred to as "composite PK functions", although this actually always meant "table PK functions", regardless of whether they were single or composite primary keys defined at the table level.

Omit only single primary key columns in insert statements

2534b1b

Renamed auxiliary function testing whether a primary key contains a c…

d359eb4

…olumn

Addressed a compiler error that occurred with msvc 141

ebae237

Validate primary key requirements up front

0de1671

Improved filter for excluding columns during serialization

aeb72b5

* Improved understanding through legibility.

Deprecated types other than 64-bit signed integer for autoincrement PKs

93a23fe

SQLite documentation clearly states that an auto-incrementable primary key column must be a 64-bit signed integer type.

trueqbit force-pushed the fix/insert-without-rowid branch from 337084c to 93a23fe Compare December 2, 2025 14:15

trueqbit added 3 commits December 3, 2025 00:20

Fixed pre-C++23 if constexpr expression

9eaf678

trueqbit changed the title ~~Fix insertion for tables without rowid~~ Correcting ordinary insert statement for tables with composite primary keys Dec 4, 2025

trueqbit marked this pull request as ready for review December 4, 2025 19:33

trueqbit requested a review from fnc12 December 4, 2025 19:40

Taking into account that the rowid key might represented by a custom …

ae205d2

…type

trueqbit force-pushed the fix/insert-without-rowid branch 2 times, most recently from 728b390 to 4007b1a Compare December 6, 2025 15:05

Deprecated types other than 64-bit signed integer for single-column PKs

0886bd5

Only types that can represent a 64-bit signed integer - either integral or custom types - have the required properties to be an alias for the rowid and can cover the whole value range of it.

trueqbit force-pushed the fix/insert-without-rowid branch from 4007b1a to 0886bd5 Compare December 6, 2025 16:04

fnc12 reviewed Dec 7, 2025

View reviewed changes

trueqbit added 5 commits December 8, 2025 10:08

Addressed compilation error with msvc 141

c6db2ec

More [[maybe_unused]] arguments

4eb9d57

Corrected typos in comments

c1a1545

trueqbit requested a review from fnc12 December 8, 2025 14:55

fnc12 approved these changes Dec 8, 2025

View reviewed changes

trueqbit added 2 commits December 8, 2025 21:56

Made documentation just a bit clearer

0b6b3d5

Simplified expression to exclude columns at compile-time

98c379c

trueqbit requested a review from fnc12 December 8, 2025 19:59

fnc12 approved these changes Dec 9, 2025

View reviewed changes

trueqbit merged commit 1ddc3b5 into dev Dec 9, 2025
3 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Correcting ordinary insert statement for tables with composite primary keys #1468

Correcting ordinary insert statement for tables with composite primary keys #1468

Uh oh!

trueqbit commented Nov 27, 2025 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fnc12 Dec 8, 2025

Uh oh!

trueqbit Dec 8, 2025

Uh oh!

fnc12 Dec 9, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Correcting ordinary insert statement for tables with composite primary keys #1468

Correcting ordinary insert statement for tables with composite primary keys #1468

Uh oh!

Conversation

trueqbit commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Improvements:

Other improvements:

Fixes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fnc12 Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

trueqbit Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 9, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

trueqbit commented Nov 27, 2025 •

edited

Loading