I am currently maintaining a DataSnap server using the old binary format (not HTTP and REST). I am considering moving to XData or maybe even TMS Business Subscription.
We have used two features extensively in our DataSnap server:
TDataSetProvider.Option poPropogateChanges (should really be propagate changes)
Correct processing of a DeltaDS (inserts on master dataset first then detail datasets & delete on detail datasets first then master dataset)
For Point 1: It is very likely that the application server may enhance the delta and store a create stamp/update stamp or even increment a version number on the record. The option poPropogateChanges allowed us to see that change on the client side after calling ApplyUpdates. What is the similar feature for XData? How would I achieve this?
For Point 2:
If changes are accumulated on the client-side are they processed in the same order on tyhe server-side as they were done on the client-side?
And last but not least: Is it possible in Aurelius to gather changes on multiple records and apply them in one REST call together, so they can be wrapped into one DB transaction on the server-side?
XData is a very different approach than DataSnap using SQL. You have such mechanisms but in a very different way.
For example, you can have all your Aurelius objects being edited at client-side, and then when everything is ready, you can send the objects to a XData method in your server that process the object tree. Or a list of objects.
Alternatively you can use RemoteDB which will allow you to still use TClientDataset and plug a RemoteDb dataset as a provider to the client dataset. But there is no feature to send all deltas at once in a single request. When ApplyUpdates is called, each SQL is sent to the server separately.
I understand that it is possible to post a set of changes made on the client-side in one call. That's good. What if the application server changes to object on its way into the database? Do I need to load all the data again to see these changes? In that case I would need to remember which objects had been in focus - in case of master/detail relationships on multiple levels - before posting my changes.
I have implemented a particular business case were setting a delivery date on an invoice cause three follow-up records being created on the server-side against that invoice. In that case I needed to get those three records via JSON from the server back into the client as part of the ApplyUpdate call. I merged them manually into my nested dataset and marked the nested dataset as "free of changes" (e.g. TClientDataSet.MergeChangeLog).
In the sample code of XData you show how to update an object:
If this server call would have a side effect (e.g updated UpdateStmp or incremented UpdNo) I got the feeling I need to reload the object to see it in the client application as it exists on the server-side.
What if the call was to delete an invoice, which still has invoice items? Is the XData user/developer required to implement the code necessary to delete the items before the invoice gets deleted by the framework?
I am referring to the TXDataWebDataSet I saw in the tutorial "From Database to Web App through REST server with TMS XData and TMS Web Core" on YouTube. Is it possible to use it in a master-detail fashion and how does the REST request look like for an ApplyUpdates in a more complex master-detail situation?
As I said, you should forget about TClientDataset when working with XData. TClientDataset is full os mechanisms that are specific to it. There is no MergeChangeLog. There is not even dataset concept (except for visual binding values to controls). It's a different paradigm.
Of course you can refresh data - You can call a server method to update a date in an invoice, create new data there, and return new data - or the client can ask the server for new data.
In the specific case of invoice/invoice items and DELETE method, deleting an invoice will delete invoice items automatically (if the cascade is defined so). But nothing prevents you to create a custom method "DeleteInvoiceMyWay" and do different things there.
Specifically about TXDataWebDataset and the XData CRUD operations which are automatically published (POST, PUT, GET, DELETE), deleting the invoice will delete the invoice items.
In that case, the master detail is represented as a tree of objects.
When you ask an invoice from the server, you can ask it to retrieve the invoice items together as a list. Such list can be assigned to a "detail" dataset to bind to visual controls so when the main dataset is displaying an invoice object, the detail dataset will display the content of its "Items" property, which will be a collection of item objects.
You can freely edit those objects using the dataset or manually. At any time, you can send back to the server the "invoice" objects including all the "items" list, and everything will be updated accordingly.