Semantics of RealmObjectBase.OnPropertyChanged()

[bdach]

Hi,

I'm looking at a potential usage of RealmObjectBase.OnPropertyChanged() that has me puzzled in a few respects.

First of all, the docs for the method state the following:

For this method to be called, you need to have first subscribed to PropertyChanged.

My interpretation of this is "if no user code has subscribed to PropertyChanged, the OnPropertyChanged() callback will never fire". This seems slightly weird, but also not what actually happens - in quick experimentation it doesn't matter as to whether something did or did not subscribe to PropertyChanged, the callback fires all the same.

For the second part, I probably need to explain the use case. In short, we have the following structure:

public class BeatmapInfo : RealmObject
{
    public string Hash { get; set; }
}

public class ScoreInfo : RealmObject
{
    public BeatmapInfo BeatmapInfo { get; set; }
    public string BeatmapHash { get; set; }
}

What we would like to achieve is to have ScoreInfo.BeatmapHash automatically pull out Hash from ScoreInfo.BeatmapInfo.Hash into ScoreInfo.BeatmapHash every time ScoreInfo.BeatmapHash is changed (but importantly, not the other way around - this is very purposefully a one-way relationship). My question here would be - is this a supported use case for OnPropertyChanged()? The documentation example is a slightly different use case as it concerns non-mapped members.

I see open issues that OnPropertyChanged() fires on transaction commit - am I correct in thinking that due to that implementation detail, using the feature in that way for our use case right now would result in essentially non-atomic writes? (I'm not super sure if this is a dealbreaker yet; the requirement of the prior transaction committing at least ensures that the transfer of hash never tries to transfer wrong values, but it may still be possible for the transaction to complete but for the property change callback-triggered writeback of the hash to fail.)

[nirinchev]

Hey, no, that's not the intended use of OnPropertyChanged. Instead, the intention there is to allow you to raise property change notifications in situations where you have a computed property that depends on persisted properties.

I'm not sure I fully understand your requirement though - you're saying every time BeatmapHash is changed, you want to disregard the change and replace it with the value from BeatmapInfo.Hash? Is this to avoid people setting an incorrect value there or?

[peppy]

I guess to answer our own question, this seems to be incorrect usage of OnPropertyChanged if we expect the hash to always be in a consistent state, as OnPropertyChanged may be delayed and fired in the future based on realm's internal state.

[nirinchev]

Using OnPropertyChanged would be a ticking timebomb since you may end up in a situation where you try to update a property outside a write transaction. Imagine a situation where you have something like this:

var scoreInfo1 = realm.All<ScoreInfo>().First();
var scoreInfo2 = realm.All<ScoreInfo>().First(); 

realm.Write(() =>
{
    scoreInfo1.BeatmapInfo = ...;
});

scoreInfo2 will receive property change notification after the transaction is committed and will attempt to set the beatmap hash outside of a write transaction. Of course, you can mitigate that by checking for differences, but it feels super brittle. Instead, my suggestion would be to replace the BeatmapInfo setter to also set the BeatmapHash:

public class ScoreInfo : RealmObject
{
    [MapTo(nameof(BeatmapInfo))]
    private BeatmapInfo PersistedBeatmapInfo { get; set; }

    public BeatmapInfo BeatmapInfo
    {
        get => PersistedBeatmapInfo;
        set
        {
            PersistedBeatmapInfo = value;
            BeatmapHash = value.Hash;
        }
    }

    // You can make the setter private here - that's alright
    public string BeatmapHash { get; private set; }

    // If you want to get change notifications for the BeatmapInfo property
    // then you need this to proxy changes to `PersistedBeatmapInfo` to `BeatmapInfo`
    protected override void OnPropertyChanged(string propertyName)
    {
        base.OnPropertyChanged(propertyName);

        if (propertyName == nameof(PersistedBeatmapInfo))
        {
            RaisePropertyChanged(nameof(BeatmapInfo));
        }
    }
}

This way the private PersistedBeatmapInfo property is stored in Realm under the BeatmapInfo name while the public BeatmapInfo property is responsible for updating the hash every time it is set.

[peppy]

Thanks for the confirmation. Your proposal is what we had originally, but minus the RaisePropertyChanged portion (which is very handy to know we can do).

[bdach]

Apologies for the initial confusion, I mixed up my words in the OP which made the explanation of the use case pretty illegible. Thanks for confirming that this was as risky as I suspected it to be.

The solution with the backing property was tried, but if I'm to believe the contributor that tried it, the backing property doesn't support backlinks if it's private, which is a bit of a dealbreaker. I'll double check on my own time.

[nirinchev]

If it doesn't work with backlinks, then that's likely an oversight/bug on our end - feel free to file an issue if that's the case and we'll take a look.