Polymorphic entities

[greenrobot]

Allow subclassing of entities.

Affects:

• Box: should baseBox.get(subclassId) return a subclass entity? Probably so.
• Queries: Querying for the base class should return all sub classes.
• Relations: if a relation references a base class, actual objects may also be sub classes.

[Miha-x64]

Creating schema for such entities looks quite complicated. How database should handle object of previously unknown subclass with many new fields?
Maybe Kotlin sealed classes may help: all allowed subclasses are known at compile-time.

[dbacinski]

I would put it at the end of backlog, we can live without polimorfic types.

[YuriDenison]

• for Kotlin sealed classes.

[greenrobot]

@YuriDenison Can you give an example why one would used sealed classes as entities?

[YuriDenison]

Simple example

sealed class Destination {
  abstract val createdAt: Long

  data class City(...) : Destination()
  data class Hotel(...): Destination()
}

It would be nice to be able to create Destination box and make queries like 'get all destinations ordered by createdAt'

[Miha-x64]

[Offtop] Why do you need data modifier here?

[motis10]

What about this issue? any updates?

[motis10]

So important to the correct usage of the library my friends. You have to fix it :)

[greenrobot]

This will introduce complexity quite a bit. Other features have a better value/cost ratio. Thus we'll put that feature a bit further down in the backlog so you know what to expect.

[motis10]

Ok

[greenrobot]

Update: ObjectBox 1.4 introduces (non-polymorphic) entity inheritance. You can check it out it now using version 1.4.0-RC and also have a look at the docs.

[Armaxis]

I have a reversed problem I'm trying to solve: I want to store subclass entities (which have 20+ fields) and be able to retrieve both subclass entities (with all the fields) and baseclass entities (only 5 fields). Is it possible to achieve using current Inheritance implementation?

The reason for this is that we have a lot of data, and each entry takes 1-2Kb of memory. On devices with limited amount of memory, we want to have a slimmed-down version of the object with only essential fields (5 fields).

[greenrobot-team]

@Armaxis Sorry, the current inheritance support persists and loads all properties.

You should thumbs up or discuss #348.

-ut

[xuanswe]

really sad because this issue is low priority. I think inheritance is a very common design pattern and should have a higher priority.

[greenrobot-team]

@nguyenxndaidev Entity inheritance (with limitations) is available since ObjectBox 1.4.
https://docs.objectbox.io/advanced/entity-inheritance

Please share what you need that is not supported right now.
-ut

[xuanswe]

Below is an example that doesn't work:

sealed class Card(...)

@Entity
data class CardA(...) : Card() {
    lateinit var session: ToOne<Session> // because of current limitation, relationships must be declared here
}

@Entity
data class CardB(...) : Card() {
    lateinit var session: ToOne<Session> // because of current limitation, relationships must be declared here
}

@Entity
data class Session(...) {
    lateinit var cards: ToMany<Card> // this line demonstrates a common use case but sadly does not work (yet?)
}

It is nice if these things are supported

Queries: Querying for the base class should return all sub classes.
Relations: if a relation references a base class, actual objects may also be sub classes.

Workaround in my project

• don't use entity inheritance
• put all properties in single entity Card
• control which properties are available for different Card types at logic layer