OK, Why Bother?
This seems a bit silly, as we did not gain much by having the database view instead of just having the simple loadListModels() function on AppEntity.Store.
In a database server, database view implementations usually have two features:
- They are read-only, and
- They can be secured separately from the underlying tables
As a result, you might expose database views as being something like a read-only API to certain types of systems (e.g., report generators) that only need access to some of the data.
SQLite’s views are read-only, but SQLite has no per-user security model the way that a database server might. This limits the usefulness of database views.
However, it may be that there are certain subsets of columns, or certain WHERE constraints, that you need to use a lot. Rather than duplicate them across many separate @Query functions, you could centralize them in a database view. That way, if the list of columns changes or the WHERE constraints need to be revised, you can do so in one spot (the view definition) instead of having to ensure that you update lots of individual queries.
Prev Table of Contents Next
This book is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license.