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 PtrInt/NativeInt (i.e. Integer under Win32), since it was type-cast as pointer for TSQLRecord published properties.
We introduced a new TID type, so that the ORM primary key would now be defined as Int64.

All the framework ORM process relies on the TSQLRecord class.
This abstract 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 ID: TID, i.e. as Int64 in mORMot.pas:

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 the SQLite3 ID/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 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.

Synopse Open Source