The idea is that instead of writing:
type TSQLRecordBlogArticle = class(TSQLRecord) ...
we write with mORMot 2:
type TOrmBlogArticle = class(TOrm) ...
I don't find this new code too confusing.
TOrm for the base class to inherit from an ORM persisted class doesn't seem ground braking.
Then we have
TRestORM for the client or server process side (instead of a single bloated
TSQLRest class), and
TRest* associated types.
To access the ORM methods, you won't call
TSQLRest any more, but a new
IRestORM interface, which will be the main entry point in your end-user code.
It is available throught a new
TRest.ORM property, and will induce a better segregation in your business code: the REST and ORM features will indeed be uncoupled, so the resulting framework code is more SOLID, therefore more maintainable.
TSQLRecord new naming convention into a plain and simple
TOrmObject were also proposed. But they won't add anything to the idea, and may be confusing because we define a class, not a record or an object type. Similarly
TOrmClass is not an option, because usually
T*Class defines a metaclass, like
TOrmClass = class of TOrm.
We get rid of all
TSQL* names, and keep SQL only for
mormot.db.sql.*.pas units, which are actually SQL processing units.
Our ORM is not SQL-only, it was in the beginning, but since years it is NoSQL too, as it can use for instance MongoDB.
Of course, there are
TSQL* types definitions available by default, so existing code will continue to work with almost no modification.
There is even a
PUREMORMOT2 conditional, which gets rid of the backward compatible type definitions, and use only the new names.
Eventually this new naming convention will become the common ground to build your applications above.