IssueTracker

Or alternatively, having a way to get access to RoomDatabase from within a DAO would allow me to roll my own transaction handling.

yea i realized the #2 is missing. Dao needs to access to the database. @Transaction might be a convenience API but it won't solve all cases.
I was thinking that we can allow you to write a method that returns `RoomDatabase` (or instance of it). Any recommendation on that part? (if we do that, we'll probably force the Dao to be abstract class and make that method not public to enforce restrictions in the Dao interface so that it stays mockable).

abstract class MyDao {
   /// MyDatabase extends RoomDatabase. Returning RoomDatabase would be valid as well.
    protected abstract MyDatabase getDatabase();
}

Agree @Transaction wouldn't solve all cases, like transactions that involve multiple DAOs or non-DAO logic.

Re #2 My initial idea was allowing an optional one-arg constructor on the dao. But your idea sounds just as well.

abstract class MyDao {
    protected MyDao(RoomDatabase database) {
        // can assign database to a field and use later
    }
}

public class MyDao_Impl extends MyDao {
    public MyDao_Impl(RoomDatabase __db) {
        super(__db);
    }
}

actually i like that constructor argument better. It can also be typed.

I think we have 3 tasks here:
add support for @Transaction annotation on abstract class Dao methods.
add a convenience method to RoomDatabase that receives a callable and runs it in a transaction.
allow abstract Dao's to have a single argument constructor which receives an instance of a T where T extends the RoomDatabase.