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
TGUID field, if needed - using
attribute as explained below.
Int64 wide primary key will allow to compute huge IDs,
which was found to be almost mandatory to implement safe multi-node
Introducing TID published properties
TSQLRecord published properties do match a class instance
pointer, so are 32 bit (at least for Win32/Linux32 executables).
TSQLRecord.ID field is declared as
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
- 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