Database
@Target([AnnotationTarget.CLASS, AnnotationTarget.FILE]) class Database
| androidx.room.Database |
Marks a class as a RoomDatabase.
The class should be an abstract class and extend RoomDatabase.
You can receive an implementation of the class via Room.databaseBuilder or Room.inMemoryDatabaseBuilder.
// Song and Album are classes annotated with @Entity.
@Database(version = 1, entities = {Song.class, Album.class})
abstract class MusicDatabase extends RoomDatabase {
// SongDao is a class annotated with @Dao.
abstract public SongDao getSongDao();
// AlbumDao is a class annotated with @Dao.
abstract public ArtistDao getArtistDao();
// SongAlbumDao is a class annotated with @Dao.
abstract public SongAlbumDao getSongAlbumDao();
}
The example above defines a class that has 2 tables and 3 DAO classes that are used to access it. There is no limit on the number of Entity or Dao classes but they must be unique within the Database.
Instead of running queries on the database directly, you are highly recommended to create Dao classes. Using Dao classes will allow you to abstract the database communication in a more logical layer which will be much easier to mock in tests (compared to running direct SQL queries). It also automatically does the conversion from Cursor to your application data classes so you don't need to deal with lower level database APIs for most of your data access.
Room also verifies all of your queries in Dao classes while the application is being compiled so that if there is a problem in one of the queries, you will be notified instantly.
Summary
Public constructors |
|
|---|---|
|
Marks a class as a RoomDatabase. |
|
Properties |
|
|---|---|
| Array<KClass<*>> |
The list of entities included in the database. |
| Boolean |
You can set the annotation processor argument ( |
| Int |
The database version. |
| Array<KClass<*>> |
The list of database views included in the database. |
Public constructors
<init>
Database(
entities: Array<KClass<*>>,
views: Array<KClass<*>>,
version: Int,
exportSchema: Boolean)
Marks a class as a RoomDatabase.
The class should be an abstract class and extend RoomDatabase.
You can receive an implementation of the class via Room.databaseBuilder or Room.inMemoryDatabaseBuilder.
// Song and Album are classes annotated with @Entity.
@Database(version = 1, entities = {Song.class, Album.class})
abstract class MusicDatabase extends RoomDatabase {
// SongDao is a class annotated with @Dao.
abstract public SongDao getSongDao();
// AlbumDao is a class annotated with @Dao.
abstract public ArtistDao getArtistDao();
// SongAlbumDao is a class annotated with @Dao.
abstract public SongAlbumDao getSongAlbumDao();
}
The example above defines a class that has 2 tables and 3 DAO classes that are used to access it. There is no limit on the number of Entity or Dao classes but they must be unique within the Database.
Instead of running queries on the database directly, you are highly recommended to create Dao classes. Using Dao classes will allow you to abstract the database communication in a more logical layer which will be much easier to mock in tests (compared to running direct SQL queries). It also automatically does the conversion from Cursor to your application data classes so you don't need to deal with lower level database APIs for most of your data access.
Room also verifies all of your queries in Dao classes while the application is being compiled so that if there is a problem in one of the queries, you will be notified instantly.
See Also
Properties
entities
val entities: Array<KClass<*>>
The list of entities included in the database. Each entity turns into a table in the database.
| Return | |
|---|---|
Array<KClass<*>> |
The list of entities in the database. |
exportSchema
val exportSchema: Boolean
You can set the annotation processor argument (room.schemaLocation) to tell Room to export the database schema into a folder. Even though it is not mandatory, it is a good practice to have version history of your schema in your codebase and you should commit the schema files into your version control system (but don't ship them with your app!).
When room.schemaLocation is set, Room will check this variable and if it is set to true, the database schema will be exported into the given folder.
exportSchema is true by default but you can disable it for databases when you don't want to keep history of versions (like an in-memory only database).
| Return | |
|---|---|
Boolean |
Whether the schema should be exported to the given folder when the room.schemaLocation argument is set. Defaults to true. |