You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: mORMot 2 » Moving to mORMot2 for multi-tier application » 2025-03-27 07:15:30
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
#2 mORMot 2 » Moving to mORMot2 for multi-tier application » 2025-03-26 09:52:08
- mathias_burbach
- Replies: 3
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
#3 Re: mORMot 1 » Some basic questions » 2020-07-17 02:00:16
Dear Administrator,
a pessimistic lock as suggested by Bernd is one option. I can understand that you do not want to implement that feature for a stateless server.
But what about optimistic locking? I am studying mORMot to decide if my next project will be done with mORMot instead of DataSnap and TClientDataSets. So far I have had a version number on each record that was incremented by the application server. The primary key value and the version number of the record was good enough to identify if the record changed since the client-side fetched the record. Obviously the server had to increment the version number and that change on the record was transported back into the client without a single line of code. Just by including the poPropogateChanges into the TDataSetProvider.Options any server-side change was transported back into the client.
I thought that TModTime would be something similar as I looked at the mORMot documentation. But in the sample project 03 NamedPipe the value is assigned on the client-side. Even if there is a chance to get this done on the server-side I would still need other properties to be updated on the server-side before they are saved in the database and that change would have to go back into the client-side without too much effort. What is the best way to achieve that with mORMot?
A sample on how TMS Aurelius handles such situations can be found here.
Salut,
Mathias
Pages: 1