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.
- Deprecated types other than 64-bit signed integral types (except for custom integer types) - it is clearly stated in the SQLite documentation that auto-increment is only valid for 64-bit signed integer columns and if they are an alias for the implicit rowid column. With SQLite it is a hard error if you try to use a type for a column other than INTEGER.
Deprecated the ordinary 'insert' statement into tables with a single-column primary key whose integral types are not 64-bit signed integers (except for custom integer types). This is because they are actually not an alias for the rowid and cannot be implicitly inserted. While we could just take the values from the specified object an explicit alternative way is available with the 'replace' and 'insert with specified columns' statements.
For type safety reasons, a 64-bit integer is finally returned as the last inserted row ID.
- The worst that can happen is a compiler warning or error depending on the compiler settings because of a narrowing conversion. Users should fix their code.

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.

fnc12 · 2025-12-07T13:22:52Z

dev/schema/column.h

            }

+            /**
+             *  Checks whether contraints contain specified class template.


typo: con[s]traints

fnc12 · 2025-12-07T13:23:20Z

dev/schema/column.h

            filter_tuple_sequence_t<Elements, mpl::disjunction_fn<is_column, is_hidden_column>::template fn>>;

-#if SQLITE_VERSION_NUMBER >= 3031000
+        // Custom type: programmer's responsibility to garantee data integrity in the value range of a 64-bit signed integer


typo: g[u]arantee

fnc12 · 2025-12-07T13:25:06Z

dev/schema/table.h

+                constexpr size_t nTablePrimaryKeyColumns =
+                    nested_tuple_size_for_t<columns_tuple_t, elements_type, pk_index_sequence>::value;
+
+                static_assert(nTablePrimaryKeyColumns > 0, "Tabel primary key definition must contain one column");


typo: Table not Tabel

fnc12 · 2025-12-07T13:30:38Z

dev/storage.h


            template<class O, class... Cols>
-            int insert(const O& o, columns_t<Cols...> cols) {
+            int64 insert(const O& o, columns_t<Cols...> cols) {


on man, it will produce a lot of warnings. I'd leave it like this just like it is done in Java (where almost all integer operations are handles by simple ints) for simplicity and if somebody wants to get more precise int64 result one can use last_insert_rowid() instead or use a prepared statement of insert. I mean this function int insert is a real legacy and I'd leave its signature like this just like the below one's

fnc12 · 2025-12-07T13:34:27Z

examples/except_intersection.cpp


 struct DeptMaster {
-    int deptId = 0;
+    sqlite_orm::int64 deptId = 0;


what happens to this example if we skip this change?

fnc12 · 2025-12-07T13:38:17Z

tests/prepared_statement_tests/replace_range.cpp

            REQUIRE(get<1>(statement) == userPointers.end());
            storage.execute(statement);
        }
+        SECTION("references") {


this type of sections is a really good shot

fnc12 · 2025-12-07T13:57:33Z

tests/tests5.cpp

                                           primary_key(&A::getAddress, &A::getType, &A::getIndex)));
    storage.sync_schema();
-    storage.replace(A(1, 1, 0, std::make_shared<double>(55.5)));
+    storage.insert(A(1, 1, 0, std::make_shared<double>(55.5)));


this is a really good bug fix

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

Open

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

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

trueqbit commented Nov 27, 2025 •

edited

Loading

Uh oh!

fnc12 Dec 7, 2025

Uh oh!

fnc12 Dec 7, 2025

Uh oh!

fnc12 Dec 7, 2025

Uh oh!

fnc12 Dec 7, 2025

Uh oh!

fnc12 Dec 7, 2025

Uh oh!

fnc12 Dec 7, 2025

Uh oh!

fnc12 Dec 7, 2025

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

Are you sure you want to change the base?

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

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!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

fnc12 Dec 7, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

trueqbit commented Nov 27, 2025 •

edited

Loading