Problem Statement
Room 2.7 introduced RoomDatabase.Builder.setDriver(SQLiteDriver) as the new way to configure an underlying SQLite implementation (link), with the intention of eventually replacing SupportSQLiteOpenHelper. (Room 3.0+ does just that.)
The Sentry Android Gradle Plugin currently auto-instruments only the open helper path. Apps that adopt the driver-based API will lose automatic SQL span creation unless they manually wrap their driver with SentrySQLiteDriver.create(...) at every setDriver(...) call site.
Solution Brainstorm
Proposed approach
Define a new ASM ClassInstrumentable + MethodVisitor pair for wrapping the parameter passed to Room.DatabaseBuilder.setDriver(SQLiteDriver). The wrapper will be the SentrySQLiteDriver introduced under JAVA-275 / #5001.
In other words, this:
val database = Room.databaseBuilder(context, MyDatabase::class.java, "dbName")
.setDriver(AndroidSQLiteDriver())
.build()becomes:
val database = Room.databaseBuilder(context, MyDatabase::class.java, "dbName")
.setDriver(SentrySQLiteDriver.create(AndroidSQLiteDriver()))
.build()The SentrySQLiteDriver implementation will need to protect against duplicate wrapping, should the driver passed to setDriver() already be wrapped.
Coverage
tl;dr: The proposed approach would cover all Room users; SQLDelight users don’t need to be covered (they still use SupportSQLiteOpenHelper); and the few developers who use SQLiteDriver directly would need to wrap manually.
1. Persistence libraries
The vast majority of developers access SQLite via a persistence library, and that library is almost always Room or SQLDelight.
Room.DatabaseBuilder.setDriver() is the sole Room 2.7+ and 3.0+ entry point for SQLiteDriver – at least for now. We'll want to monitor the API as it evolves. (Room first supported SQLiteDriver in 2.7.0-alpha01.)
SQLDelight doesn’t officially support SQLiteDriver; it uses SupportSQLiteOpenHelper instead (link). But there's a third-party bridge library (link). Use of the bridge library isn’t widespread (90 stars, 6 forks), so we don't plan to support its creation pattern (link). We can revisit if there's sufficient community demand.
2. Direct SQLiteDriver use
Under the proposed approach, the few developers whose use SQLiteDriver directly would need to wrap it manually. Eg, AndroidSqliteDriver().open() -> SentrySQLiteDriver.create(AndroidSqliteDriver()).open().
Problem Statement
Room 2.7 introduced
RoomDatabase.Builder.setDriver(SQLiteDriver)as the new way to configure an underlying SQLite implementation (link), with the intention of eventually replacingSupportSQLiteOpenHelper. (Room 3.0+ does just that.)The Sentry Android Gradle Plugin currently auto-instruments only the open helper path. Apps that adopt the driver-based API will lose automatic SQL span creation unless they manually wrap their driver with
SentrySQLiteDriver.create(...)at everysetDriver(...)call site.Solution Brainstorm
Proposed approach
Define a new ASM ClassInstrumentable + MethodVisitor pair for wrapping the parameter passed to
Room.DatabaseBuilder.setDriver(SQLiteDriver). The wrapper will be theSentrySQLiteDriverintroduced under JAVA-275 / #5001.In other words, this:
becomes:
The
SentrySQLiteDriverimplementation will need to protect against duplicate wrapping, should the driver passed to setDriver() already be wrapped.Coverage
tl;dr: The proposed approach would cover all Room users; SQLDelight users don’t need to be covered (they still use SupportSQLiteOpenHelper); and the few developers who use SQLiteDriver directly would need to wrap manually.
1. Persistence libraries
The vast majority of developers access SQLite via a persistence library, and that library is almost always Room or SQLDelight.
Room.DatabaseBuilder.setDriver()is the sole Room 2.7+ and 3.0+ entry point for SQLiteDriver – at least for now. We'll want to monitor the API as it evolves. (Room first supported SQLiteDriver in 2.7.0-alpha01.)SQLDelight doesn’t officially support SQLiteDriver; it uses SupportSQLiteOpenHelper instead (link). But there's a third-party bridge library (link). Use of the bridge library isn’t widespread (90 stars, 6 forks), so we don't plan to support its creation pattern (link). We can revisit if there's sufficient community demand.
2. Direct SQLiteDriver use
Under the proposed approach, the few developers whose use SQLiteDriver directly would need to wrap it manually. Eg,
AndroidSqliteDriver().open()->SentrySQLiteDriver.create(AndroidSqliteDriver()).open().