If you haven’t read my previous post about setting up the Room I highly recommend to check it out first. Also repo with examples is https://github.com/iwuvhugs/Choice

If you’ve done steps from that article you have app with one table and couple queries aka classic-new-library-tutorial-app. However in real life you probably need more than one entity in your app.

Assume you already have app with a single table. Let’s add second table for . and will have one-to-many relation.

Like before, you start with data class that represent your entity or table in the database. New thing in is . Foreign keys allow you to specify constraints across Entities. can accept multiple keys, in my example I have only one. accepts class name or which the table should have a relation with, which specify keys in the parent table (could be several keys - I have just one in the example), which specify keys in the current table (could be several keys as well). In addition you could add and actions that will be triggered when parent table is deleted or update. In my example I do cascading i.e. when question is deleted all its answers will be deleted too.

Then you need to create DAO for answers table. Pretty much the same thing as questions.

I have two database operations here just as an example.

Then you need to add entity and DAO into you database class:

Also you’ll need to bump you database version. You can architect you database in one step but in real life you will likely need to add new tables with new release so you’ll need to migrate the database.

If you try to run app at this point you will likely get a crash that looks like:

This is a very cool feature of Room. If schema was changed you will find it really quick. Moreover app won’t compile until you fix it. To fix it you need to write a migration.

Now I probably teach you some bad development practices but nobody told me that this is bad so ¯\_(ツ)_/¯. If your SQL skill are weak (like mine haha) Room gives you some hints for migrations. When you try to run the app and get the crash, Room still generates new schema. You can open new version of schema and compare the diff with previous version. I personally find it helpful. In my example new entity was added (obvious but also schema.v2 shows that 😉) so the migration should have a query to create this table. I just found the query in the schema for creating table and copy pasted it in the migration.

Good practice here will be to extract table and column name as constants but I might do it later. Also in the article it seems like more clear to read.

Then you need to add that migration when initialize you database. In my example it was in application class so the code will be:

accepts so you just list all your migrations here. Or create a util class that is responsible for organizing all migrations.

Now if everything is done correct app should compile successfully. Congrats, you have two tables now.

P.S. It’s not easy to adapt new library. When I decide to learn something new I never read documentation first. I mostly google <library name> example or tutorial. Very often I end up reading Medium article and then following steps from it. Sometimes it’s frustrating when an article ends quick showcasing only kind of examples. I have couple more ideas for another article (maybe couple) about Room but if you have any ideas of helpful things to document, please leave comments, and then I could totally try in in the app and share some results in another article.

Mobile developer, snowboarder, dog lover

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store