BREAKING CHANGE - TSQLRecord.ID primary key changed to TID: Int64
Up to now, the
TSQLRecord.ID property was defined in
mORMot.pas as a plain
Win32), since it was type-cast as pointer for
We introduced a new
TID type, so that the ORM primary key would
now be defined as
All the framework ORM process relies on the
TSQLRecord class features a lot of built-in methods,
convenient to do most of the ORM process in a generic way, at record level.
It first defines a primary key field, defined as
TID, i.e. as
type TID = type Int64; ... TSQLRecord = class(TObject) ... property ID: TID read GetID write fID; ...
In fact, our ORM relies now on a
Int64 primary key, matching
RowID primary key.
This primary key will be used as RESTful resource identifier, for all CRUD operations.
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