mORMot Open Source

mathias_burbach

Member

Registered: 2020-07-11

Posts: 3

Moving to mORMot2 for multi-tier application

Dear mORMot2 user base,

we are considering to use mORMot2 for a new project that will need an application server and a Delphi VCL front-end. In previous projects we have used DataSnap.

I had a look at the examples of mORMot2 and wanted to understand how the blog application saves a new post. I was surprised to see that each article was is sent to the server as a set of parameters instead of a model instance (e.g. TOrmArticle). Is the serialisation able to sent a complete model instance maybe even with dependent model classes? I ask this as we previously have implemented multi-step wizards using nested datasets with all sorts of changes on any given step (e.g. nested dataset). We would like to reproduce this behaviour as all changes need to be done within one database transaction.

Last but not least we would need to know if any changes done to the model class on the server-side as part of a Wizard.SaveChanges (like TBlogApplication.ArticleCommit) can be transported back to the client and merged into the client-side representation of the model without too much hassle? In DataSnap we only had to enable the propagation of changes done to the delta inside a dataset provider events and those changes would travel back to the client without the need of fetching the model/dataset again (e.g. TDataSetProvider.Options = [poPropogateChanges, ...]).

We are looking forward to your advice and hope to find a smooth path from DataSnap to mORMot2.

Salut, Mathias

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,928

Website

Re: Moving to mORMot2 for multi-tier application

For the mORMot serialization, published properties of a class instance are serialized too. Serialization is done at RTTI level, so ORM is not involved here.

I guess about "application server" you meant a dynamic HTML server?
This is what the MVC blog application is about.
But perhaps you are confused here.

If "application server" means a regular REST/JSON server, then don't use the MVC classes, but the service features of the framework.
Either directly the HTTP server with events, or the mORMot REST server using interface-based services.
You "may" publish the ORM directly to the client (the framework can provide a REST endpoint to this), but we don't advice it for any serious business logic.

There is no "TDataSet changeset" support in mORMot.
For changes, we have a TRestBatch feature instead, which makes the transaction directly on the server side.

mathias_burbach

Member

Registered: 2020-07-11

Posts: 3

Re: Moving to mORMot2 for multi-tier application

Merci beaucoup, Arnaud.

The TRestBatch is exactly the equivalent to what we are used to in DataSnap world, including the MaxErrors parameter.

What about nested classes, so changes against a TCustomer with multiple TOrder instances (e.g. TCustomer.Orders: TOrderList) and several TOrderItem(s) (e.g. TOrder.Items: TOrderItemList)? Is RTTI enough to handle this or do we need to add each changed TOrmClass descendent into the batch, one by one? Can a batch contain different TOrmClass descendents? If so, is the client responsible for the correct order of the batch? For example new customers first before orders for a new customer and deleted orders first before deleting a customer? The TClientDataSet kept track of the >>change order<< for us and applied them in the same sequence on the server-side.

Is there any better option than loading all data again after a TRestClient.BatchSend, if the server has to enhance the batch (e.g. Adding a primary key value, setting a version number on the TOrmClass descendent or enhancing the batch in any other form or shape)? This TDataSetProvider.Options = [poPropogateChanges, ...] with zero lines of code on the client-side was quite helpful in DataSnap.

Thanks for your additional feedback up-front.

Salut, Mathias

Last edited by mathias_burbach (2025-03-27 07:17:54)

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,928

Website

Re: Moving to mORMot2 for multi-tier application

About nested classes, our ORM has some limitations.
You need to use a specific class, TOrmMany, with specific fields for a pivot table.
The main idea is that our ORM is good for "aggregates" objects, and usually if you need a lot of variable information, you could use a variant field, and this field some JSON will be stored on the database, and accessed as TDocVariant from the source code. Or if you put some TPersistent property, it will be serialized also as a JSON object. If you put a dynamic array of TPersistent or records, they will be serialized as JSON array in the database.

About primary keys, or version numbers, those are handling by the ORM itself directly, as specific fields.
The mORMot 1 documentation applies well to mORMot 2 (just change the names e.g. from TSQLRecord* into TOrm*).
https://synopse.info/files/html/Synopse … IDE_TITL_3
In short: don't expect direct DataSnap-like features, but some other ways of doing similar things, more oriented at source code than TDataSet.

Consider using an interface-based service, if possible hiding most of the ORM part, when switching to mORMot 2.
Don't focus on the DB, but on the usecases.