How to model sub entities like in CoreData?


Is it possible to have some sort of sub records, like CoreData has sub entities?
E.g. I want to store graphics objects in a single table, but 'circle' needs slightly different properties (columns) than 'rectangle', but they all have a common set of properties ('graphic'). I would in this case call the table 'graphic'.

Thanks in advance.

Kind regards,

Remco Poelstra

Hello @remcopoelstra,

This topic has not been explored yet!

I personally don't quite know what Core Data has to offer there, and your message makes me think of Room's @Embedded.

Is it what you're after? Don't hesitate to elaborate, describe your pain points with the current GRDB apis, and suggest improvements, will you?


I don't have any pain points at the moment, I'm so new to GRDB that I don't know where to start...
So this is more a '(how) can I do it?' question rather than a 'it would be cool if GRDB adds support for it' question.
The Room's @Embedded solution seems to be something else, but I'm unfamiliar with Android, so it might achieve the same goal.
In CoreData, I can model my data like so:
Schermafbeelding 2020-05-15 om 08.33.47

This would result in a table (more or less) called 'graphic' with the columns xPos, yPos, width, height, diameter.
The generated code would be along the lines of: (NSObjects in reality)

class Graphic {
    var xPos
    var yPos
class Rectangle: Graphic {
    var width
    var height
class Circle: Graphic {
    var diameter

You can then query CoreData for all e.g. Graphic objects or only Circles (with or without certain predicates).

Well... you start right on a blank page :sweat_smile:

You are looking for database inheritance. This is all uncharted territory to me, but I can give a few hints:

Start by setting up the database schema first. Do you want:

  • one table per type?
  • one single table with one discriminant column?
  • one table for the base type, and one table per derived type with a foreign key to the main type?

There may exist other solutions as well. All those choices come with benefits and drawbacks that can be evaluated in the context of your specific application. I personally favor schema robustness and strong relational constraints, but I know that it's difficult to model inheritance in a relational database without some kind of "hole", and YMMV.

After this is done, how do you model this in Swift, with record types? Beware the results of GRDB requests contain one type, instantiated with the init(row:) initializer. Since Swift has no factory initializer yet, you will be unable to instantiate here a Rectangle and there a Circle.

It thus looks that composition will be preferred over inheritance (at least on the GRDB boundary).

And now, on the broader subject of database inheritance and relations (imagine a Canvas table which has many Graphics), I suggest checking out this article, which pounders many options: Modeling Polymorphic Associations in a Relational Database | Hashrocket

I'm sorry I can't get more specific. Maybe GRDB will evolve some kind of built-in support for inheritance, but today we need fearless explorers. Fortunately, there's abundant literature on the subject that can guide us.