Auto-instrument direct use of SQLiteDriver
Problem Statement
#1285 adds auto-instrumentation for SQLiteDriver when it's passed to RoomDatabase.Builder.setDriver(). That covers the most common case. But SentrySQLiteDriver is general-purpose and can wrap any androidx.sqlite.SQLiteDriver, not just ones used with Room.
Developers who use SQLiteDriver directly (e.g. BundledSQLiteDriver().open("my.db")) currently need to manually wrap it with SentrySQLiteDriver.create(...) to get SQL spans. If there's sufficient interest, we could extend the Gradle plugin's auto-instrumentation to wrap SQLiteDriver at all usage sites across the codebase, not just at RoomDatabase.Builder.setDriver().
Note: At the moment, SQLDelight doesn't officially support SQLiteDriver (cf. here).
What this would look like
Today (after #1285), the plugin only transforms setDriver() calls on RoomDatabase.Builder:
// Instrumented automatically
Room.databaseBuilder(context, MyDatabase::class.java, "dbName")
.setDriver(BundledSQLiteDriver())
.build()
// NOT instrumented / requires manual wrapping
val driver = BundledSQLiteDriver()
val connection = driver.open("my_database.db")
With codebase-wide instrumentation, both patterns would be covered automatically.
Considerations
- Scope: Would require instrumenting a broader set of classes. Any class that calls methods on
SQLiteDriver (like open()), or any constructor/factory that produces a SQLiteDriver instance. The exact approach needs design work.
- Build time: More classes to scan and transform means longer build times. The current Room-only approach is deliberately narrow to keep builds fast.
- Overlap with Room:
SentrySQLiteDriver.create() already protects against double-wrapping (it returns the delegate unwrapped if it's already a SentrySQLiteDriver, or if it's a SupportSQLiteDriver that's already instrumented via the open-helper path). So broader instrumentation wouldn't conflict with the existing Room instrumentation.
- Demand: Direct
SQLiteDriver usage outside of Room is uncommon today, but may grow as the AndroidX SQLite API matures.
How to express interest
If you'd benefit from codebase-wide SQLiteDriver auto-instrumentation, please upvote this issue or leave a comment describing your use case.
Auto-instrument direct use of
SQLiteDriverProblem Statement
#1285 adds auto-instrumentation for
SQLiteDriverwhen it's passed toRoomDatabase.Builder.setDriver(). That covers the most common case. ButSentrySQLiteDriveris general-purpose and can wrap anyandroidx.sqlite.SQLiteDriver, not just ones used with Room.Developers who use
SQLiteDriverdirectly (e.g.BundledSQLiteDriver().open("my.db")) currently need to manually wrap it withSentrySQLiteDriver.create(...)to get SQL spans. If there's sufficient interest, we could extend the Gradle plugin's auto-instrumentation to wrapSQLiteDriverat all usage sites across the codebase, not just atRoomDatabase.Builder.setDriver().Note: At the moment, SQLDelight doesn't officially support
SQLiteDriver(cf. here).What this would look like
Today (after #1285), the plugin only transforms
setDriver()calls onRoomDatabase.Builder:With codebase-wide instrumentation, both patterns would be covered automatically.
Considerations
SQLiteDriver(likeopen()), or any constructor/factory that produces aSQLiteDriverinstance. The exact approach needs design work.SentrySQLiteDriver.create()already protects against double-wrapping (it returns the delegate unwrapped if it's already aSentrySQLiteDriver, or if it's aSupportSQLiteDriverthat's already instrumented via the open-helper path). So broader instrumentation wouldn't conflict with the existing Room instrumentation.SQLiteDriverusage outside of Room is uncommon today, but may grow as the AndroidX SQLite API matures.How to express interest
If you'd benefit from codebase-wide
SQLiteDriverauto-instrumentation, please upvote this issue or leave a comment describing your use case.