Breaking Changes
List of changes in each version that breaks backward compatibility from a previous version.
Version 4.3
TXDataWebDataset now creates string fields (TStringField) for XData entity properties that are enumerated types. In previous versions, integer fields were created. This is actually a bug fix. Integer fields are used for enumerated types when using TMS Aurelius directly in desktop/mobile applications, because an enumerated type in Delphi is, in the end, an ordinal (integer) type.
For TMS Web Core, though, there are no entities, but a direct manipulation of the JSON returned by XData. And in XData JSON representation, an enumerated type is represented as a string (the enum name). For modifying or inserting such property in an entity, user need to provide the string value.
This is a bug fix but breaks existing applications. If by any chance you need to keep the enum fields as integers, set TXDataWebDataset.EnumAsIntegers property to true.
Version 3.0
This version is the first "official" (non-beta) support for TMS Web Core, and it has renamed two key components:
TXDataWebDataset (formely TXDataDataset)
TXDataWebConnection (formely TXDataConnection)
If you have used a previous version and used the above components in TMS Web Core applications, you might get an error "TXDataConnection not found" when opening the form asking for Cancel or Ignore. Just click Cancel, close the project, and open the offending .pas/.dfm in your preferred text editor (not Delphi - it can be Notepad, for example).
Then replace any occurrence of TXDataDataset with TXDataWebDataset, and any occurrence of TXDataConnection with TXDataWebConnection, in both .pas and .dfm files. Save the files and this will fix the issue.
Version 2.9
OnEntityModifying event was being fired before merge operation thus not providing correct information about the object in manager and previous state. In case you want to go back to the previous behavior, set _FixEntityModifyingOnUpsert global variable to false.
uses XData.Server.Module;
_FixEntityModifyingOnUpsert := False;
Version 2.1
- TXDataServerModule.PutMode property controls how PUT will behave at server-side.
Version 1.5.2
This version fixes a bug that the header xdata-expandlevel was being ignored when returning entity sets. Even though it's a bug fix, this is a breaking change as the server changed its behavior.
Version 1.1
a. Example provided in Building The Entity Model topic has changed to illustrate how to correctly build the model in version 1.1 (TXDataModelBuilder constructor and Build method changed the signature).
b. Model is not owned by the TXDataServerModule class and must be now destroyed explicitly. So in the following code:
XDataServerModule := TXDataServerModule.Create(MyUrl, MyConnectionPool, MyModel);
now you need to destroy the model when the server is shutdown:
MyModel.Free;
Note this is not a critical issue because if there is a leak, it will only happen when the whole server application is shutdown. Also, with the new multiple model feature, it's very rare that you would need to create your own model explicitly.
Version 2.1 - Breaking Changes
Version 2.1 introduces the TXDataServerModule.PutMode property which defines how PUT requests will be implemented by the server. The two options are "Update" and "Merge". Basically, the server receives the object to be updated in JSON, deserializes it to an object, and uses the TMS Aurelius TObjectManager and either the Update or the Merge method:
// TXDataPutMode.Update
Manager.Update(ReceivedObject);
Manager.Flush;
// TXDataPutMode.Merge
Manager.Merge(ReceivedObject);
Manager.Flush;
The breaking change here is that until the version prior to 2.1, the one and only behavior was Update. Now, the default has changed to Merge. We're not aware of any serious issue with this change, but the behavior has changed in some specific cases - for the better. Suppose you have a JSON request with the following object:
{
"$id": 1,
"@xdata.type": "XData.Default.Product",
"Id": 10,
"Name": "Ball",
"Category1": {
"$id": 2,
"@xdata.type": "XData.Default.Category",
"Id": 5,
"Name": "Toys"
},
"Category2": {
"$id": 2,
"@xdata.type": "XData.Default.Category",
"Id": 5,
"Name": "Toys"
}
}
In the example above, the client is sending a Product entity which has two category properties: Category1 and Category2. Both properties are pointing to the same "Toys" category (id = 5) so the PUT request is intending to set both product categories to "Toys".
With the previous behavior, the server would raise an error, because there are two different instances of the same category in the product. With the new Merge behavior, the PUT request will process just fine.
In any case, if you want to go back to the previous behavior you can just set TXDataServerModule.PutMode property to TXDataPutMode.Update.