SQLiteTime - controls the printing of wall-clock time taken to execute SQL statements as they are executed.SQLiteStatements - controls the printing of SQL statements as they are executed.SQLiteLog - controls the printing of informational SQL log messages.If we check the source code of SQLiteDebug class, we will find 3 possible log tags, which you can use to log different SQLite things: But is it the only way to do that? Maybe it’s possible to check all the queries Room is generating to identify some abnormalities? Spoiler: yes, it is possible. That’s a tough one to debug, since you have to dig down into the Room library, creating a breakpoint hell, setting a lot of debugger watches and overall doing many unpleasant things. After some time of debugging, I found out that our Flow doesn't emit some of the changes in the database. One sunny day, one of our testers reported a bug about wrong behaviour on one of our screens. If this contact will be changed in the database sometime in the future, new Flow emission will notify us about * FROM contacts WHERE id = :contactId')Ībstract fun getContactStream(contactId: Long): Flow For example, here we have a method that returns Flow of a contact. Since we are strong Kotlin Coroutines supporters 💪, we mostly use Room in conjunction with Kotlin Coroutines. The most popular would be RxJava Observable, Kotlin Coroutines Flow and PagingSource from Paging library.

When querying, there are a lot of adapters which can be used to return different types of data. In this post, we are going to learn how to use some of the debugging tools that SQLite/Android Room library provides in case standard tools are not helping. For Android, there is Android Room library, which is essentially a wrapper around SQLite. SQLite uses SQL and therefore allows the use of all its features such as inserting, updating, deleting data, joining tables, querying, etc. SQLite is one of the most popular databases when it comes to choosing persistence technology for Android.

Sqlite3 android