As of now, Stateprinter has focused on printing state from memory. There is nothing wrong with printing state read from a subset of a database. Eg.
printer.PrintTable("SELECT TOP y x,y,z FROM a WHERE b", "rows of a", conn)
printer.PrintTable(string sql, string rootname, Connection conn)
or
printer.PrintTable(IQueryable<T> q, string rootname)
possibly for the method taking sql as an argument, we need an overload taking a transaction such that we can read data that is not yet committed (and might need to be rolled back, eg. in a unit test)
As of now, Stateprinter has focused on printing state from memory. There is nothing wrong with printing state read from a subset of a database. Eg.
or
possibly for the method taking sql as an argument, we need an overload taking a transaction such that we can read data that is not yet committed (and might need to be rolled back, eg. in a unit test)