Limitation or feature?

You may be disappointed by this limitation, which is needed by the SQLite3's implementation of Virtual Tables - see Virtual Tables magic.

We won't debate about a composite primary key (i.e. several fields), which is not a good idea for an ORM.
In your previous RDBMS data modeling, you may be used to define a TEXT primary key, or even a GUID primary key: those kinds of keys are somewhat less efficient than an INTEGER, especially for ORM internals, since they are not monotonic.
Note that you can always define a secondary key, as string or TGUID field, if needed - using stored AS_UNIQUE attribute as explained below.

Having Int64 wide primary key will allow to compute huge IDs, which was found to be almost mandatory to implement safe multi-node replication.

Introducing TID published properties

TSQLRecord published properties do match a class instance pointer, so are 32 bit (at least for Win32/Linux32 executables).
Since the TSQLRecord.ID field is declared as TID = Int64, we may loose information if the stored ID is greater than 2,147,483,647 (i.e. a signed 32 bit value).

You can now define a published property as TID to store any value of our primary key, i.e. up to 9,223,372,036,854,775,808.
Note that in this case, there is no information about the joined table.

As a consequence, the ORM will perform the following optimizations for TID fields:

  • An index will be created on the database, for the corresponding column;
  • When a referenced record is deleted, the ORM won't do anything, since it has no information about the table to track - this is the main difference with TSQLRecord published property.

See the corresponding updated documentation.
Feedback is welcome on our forum, as usual.