Skip to content

Auto-instrument direct use of SQLiteDriver #1338

Description

@0xadam-brown

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.

Metadata

Metadata

Assignees

No one assigned

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions