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 TRest and 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.
About the TSQLRecord new naming convention into a plain and simple TOrm, TOrmRecord and 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.
