As you can see, there’s no explicit storage variable used in this example. This is basically case (2) from my description of the variations of simplified property implementation. For delayed property implementation this is the recommended syntax from XPO 7.1 onwards – the one disadvantage outlined for case (2) was the absence of the local storage field. This is not a disadvantage for delayed properties, as the storage field itself (the one of type XPDelayedProperty) wasn’t any use for the programmer anyway.

So what’s that about a breaking change?

There are two important details that may change your application’s behaviour to some degree:

Setting the delayed property value now fires an OnChanged event – a good thing, but a change nevertheless.

For the change notification, the old value of the delayed property will be fetched from the database if it hadn’t been fetched previously.

Note: This change is only in the final 7.1 version of XPO, not in the RC that is currently available.