get Realm instance from RealmObject

[yamamotoj]

Goal

To get Realm instance from RealmObject inheriting object when it is managed.
It was possible in the previous version ( e.g. 0.87.2).

Use Case

Our application have something like news feed.
The feed item has several kind of information.
In the new feed list view, almost same information is displayed for all kind of item.
When an user tap the feed list item in the feed list view,
a kind specific detail feed information is displayed in addition to common feed item information.

I am realizing following data structure on Realm 0.87.2.

FeedItem class is a realm object for common feed list item information,
A realm object for kind specific detail feed information is defined for each kind,
and implements FeedItemDetail interface.

To realize polymorphism like behaviour which is not supported by realm object,
I add getFeedDetail() method with FeedItemDetail return type to FeedItem class with @ignored annotation.
In the getFeedDetail(), I get Realm instance and find feed detail object instance with realm query.
It was possible, because I could get Realm from RealmObject.
So I want make RealmObject to get realm instance.

Sample codes are like this.

public interface FeedItemDetail{
   /* ... */
}

public class CardUpdateDetail extends RealmObject implements FeedItemDetail{

    @PrimaryKey
    private String feedId;

    /* ... */
}

public class SharedLinkDetail extends RealmObject implements FeedItemDetail{

    @PrimaryKey
    private String feedId;

    /* ... */
}

public class FeedItem extends RealmObject{

    /** kind of feed item */
    private int kind;
    @Ignored
    private FeedItemDetail feedItemDetail;

    FeedItemDetail getFeedItemDetail(){
         if(this.feedItemDetail != null){
            return this.feedItemDetail;
        }
        switch(this.kind){
            case FEED_ITEM_KIND_CARD_UPDATE:
                this.feedItemDetail = getRealm().where(CardUpdateDetail::class).equals("id", id).first()
                return this.feedItemDetail;
            case FEED_ITEM_KIND_SHARED_LINK:
                this.feedItemDetail = getRealm().where(SharedLinkDetail::class).equals("id", id).first()
                return this.feedItemDetail;
            case .....
        }
    }
}

[Zhuinden]

I've seen this asked in #3042 and also at #4567 maybe with enough actual use-cases it might be reconsidered

In the meantime, final Realm realm = (Realm) ((MyObjectRealmProxy)(myObject)).realmGet$proxyState().getRealm$realm(); would work.

---

But your polymorphism would have been easier if you had just used single-table-inheritance (a single discriminator column and use 1 RealmObject for the whole class hierarchy). Much easier for queries, especially if feedId represents the "same" table in each element.

See “I don’t really need polymorphism, I just need multiple classes that slightly differ from one another, but share some of the same elements” in https://hackernoon.com/designing-the-schema-of-realm-effectively-and-other-realm-tips-feb76c5b6072

[cmelchior]

One thing that makes this a little tricky is the difference between DynamicRealm and Realm

This means there is a number of challenges:

• Some code bases do not use Realm classes at all, but only DynamicRealm. In those cases having only obj.getRealm() returning a Realm instance doesn't make sense since it would be an unusable instance.

• Having both getRealm() and getDynamicRealm() would also be strange, since you would then need to know the origin of the RealmObject anyway.

• Having getRealm() on RealmObject and getDynamicRealm() on DynamicRealmObject is probably the lesser evil, but it still mean that getRealm() would appear on DynamicRealmObject since it extends RealmObject and there it doesn't make a lot of sense.

At this stage of the API I would be inclined to say that the drawbacks are bigger than the benefits.

But with the introduction of support for primitive lists ( #4165 ), we most likely end up relaxing our current generic restrictions: RealmResults<? extends RealmModel> to RealmResults<Object>. Doing this means we are opening up for the possibility of splitting DynamicRealmObject and RealmObject into two completely separate classes instead of now where DynamicRealmObject extends RealmObject.

We haven't fully fleshed out the impact on the API yet, but it would be worth keeping this use case in mind then.

[Zhuinden]

Agh, the tricky thing is that DynamicRealm does not extend Realm, it extends BaseRealm.

[cmelchior]

Yes, the difference between accepting String and Class<? extends RealmModel> is extremely painful since it surfaces in all our API's.

The original design had DynamincRealm/DynamicRealmObject/DynamicRealmList/DynamicRealmResults/DynamicRealmQuery as completely separate classes. We decided to drop that because it inflated our API surface more than we would have liked, but it would have made this use case a lot easier to implement.

[zaki50]

How about providing RealmObject.getRealmConfiguration(RealmModel) instead?
Users can freely use Realm.getInstance() and DynamicRealm.getInstance() with returned configuration.

It solves the issue of DynamicRealm and it does not have lifecycle management issue of returned realm instance.

What do you think?