DBFlow provides a few ways to retrieve information from the database. Through the Model classes we can map this information to easy-to-use objects.
DBFlow provides a few different ways to retrieve information from the database. We can retrieve synchronously or asynchronous (preferred).
We can also use ModelView (read here) and @Index (read here) to perform faster retrieval on a set of data constantly queried.
Synchronous Retrieval
Using the SQLite query language we can retrieve data easily and expressively. To perform it synchronously:
databaseForTable<Employee> { db ->// listval employees = (select from Employee::class).queryList(db)// single result, we apply a limit(1) automatically to get the result even faster.val employee: Employee? = (select from Employee::classwhere Employee_Table.name.eq("Andrew Grosner")).querySingle(db)// can require result to get non-null if you know it exists// throws a SQLiteException if missingval employee: Employee? = (select from Employee::classwhere Employee_Table.name.eq("Andrew Grosner")).requireSingle(db)// get a custom listval employees: List<AnotherTable> = (select from Employee::class) .queryCustomList(database)// custom objectval anotherObject: AnotherTable? = (select from Employee::classwhere(Employee_Table.name.eq("Andrew Grosner"))) .queryCustomSingle()// require custom objectval anotherObject: AnotherTable= (select from Employee::classwhere(Employee_Table.name.eq("Andrew Grosner"))) .requireCustomSingle()}
To query custom objects or lists, see how to do so in QueryModel.
Also you can query a FlowCursorList/FlowTableList from a query easily via queryCursorList() and the queryTableList() methods. To see more on these, go to Flow Lists.
Asynchronous Retrieval
DBFlow provides the very-handy Transaction system that allows you to place all calls to the DB in a background queue. Using this system, we recommend placing retrieval queries on this queue to help prevent locking and threading issues when using a database.
We wrap our queries in a beginTransactionAsync block, executing and providing call backs to the method as follows:
A ITransaction<R> simply returns a result, R , which could be a query, or a result from multiple queries combined into one result.
By default the library uses an ordered queue that executes FIFO (first-in-first-out) and blocks itself until new Transaction are added. Each subsequent call to the database.beginTransactionAsync places a new transaction on this queue.
If you wish to customize and provide a different queue (or map it to an existing system), read up on Transactions. We also provide constructs such as coroutines and RX Observables to map to your team's needs.
database.beginTransactionAsync { db ->
// body of transaction. Return the value you wish to pass into the Success callback.
(select from TestModel1::class
where TestModel1_Table.name.is("Async")).querySingle(db)
}
.execute(
ready = { transaction -> }, // called when transaction is ready to be executed.
success = { transaction, r -> }, // if successful
error = { transaction, throwable -> }, // any exception thrown is put here
completion = { transaction -> }) // always called success or failure
// or inverse is supported
(select from TestModel1::class
where TestModel1_Table.name.is("Async")).async { d -> querySingle(d) }
.execute { _, model: TestModel1? ->
}