In response to the question from <@U0BFDUP0E> abou...

# multiplatform

[Bradleycorn]

In response to the question from @jw about what I need from Room that SqlDelight doesn’t have:
1. Room’s @Relation annotation https://developer.android.com/reference/androidx/room/Relation. Writing huge mapper functions to create “hierarchical” models from complex queries with joins, or stitching together a model from the results of several individual table queries is a huge time suck. Room does it for me, saving me a ton of time.
2. Being able to have a table in my database with one name, and the kotlin data class in my code use a different name, for example:

@Entity(tableName="dbTable")
data class MySuperCoolModel( ... )

A few other things that you can do with both, but I prefer room’s approach:
1. Type Adapters. With SqlDelight, I have to instantiate an Adapter for every. single. table. that has custom column types, even if the same custom type is used on several tables. With room I can add a single set of adapters on the database itself, and it applies to any/all tables in the database. It’s less code. I’m good for at least one failed build every time I add a new table/column with a custom type, because I forget that I have to go add an adapter for that table to my Database constructor call, despite the fact that the custom type is already in use in several other tables.
2. Jake said: “Other than the added boilerplate of having to manually maintain the database models rather than having them automatically generated based on your schema.” … I wouldn’t say it’s added boilerplate. It’s just different boilerplate. With room I write the data models and room generates the schema. With SqlDelight I write the schema and and sqlDelight generates the models. Personally, I prefer room’s approach. First, I prefer to write Kotlin as much as I can, and as little SQL as I can get away with. Second, I often times need to add additional functionality/properties to models. You can still do this with SqlDelight by writing extension functions/properties, but now you have multiple files in different locations that define the model class’s api. Not to mention if I want private properties/methods, I can’t do that with SqlLight. With room’s approach, my entire model is defined in one location, including any extra/additional properties/methods that are not persisted in the database.
I like SqlDelight and there are plenty of things it does better than Room, but there are some things that I feel like Room does better.