Adapt Models to the needs of the application

[georgeef]

Problem

Models are organized according to database tables and they currently contain all data from one table. The application Views usually need combined data. Typically the main data comes from one database table, but auxiliary data is also need from other tables.

Proposal

As first step to adapt the Models to the needs of Views, the following data structures are provided for each model, where <M> is Currency, Account, etc.:

• <M>Data contains all data found in the corresponding database table (currently this data is stored in <M>)
• <M>Full contains <M>Data plus auxiliary information, found in the linked records

For example

• AccountFull contains data from Currency,
• TransactionFull contains data from Account, Category, Payee, Tag, Attachment, SplitTransaction, etc.

Views can fetch <M>Full, which contains all data they need, and focus mostly on the presentation of data, rather than on data collection from different sources. This simplifies the implementation of Views.

Efficiency improvements

The full data might be an overkill, since List Views typically need only main info for many records, while Detail Vies need all data for only one record.

As a future optimization, Models can be further tailored to the needs of List and Detail Views, by offering the information that is really needed. With this approach, the Models can deviate from the one-to-one correspondence with database tables, and Views will need to fetch only one data structure with all needed data inside.

[georgeef]

VM for Transaction

Transaction refers to the following tables:

• SplitTransaction
• Currency
• Account
• Asset
• Stock
• Category
• Payee
• Tag
• CustomField
• Attachment

It is the only table with so many dependencies (Scheduled has a few less, other tables much less).

Typically the following tables are small and they are needed very often; they can be pre-fetched or cached (instead of fetching their data with join queries):

• Currencies (only those that are used in Accounts, no need to pre-fetch all)
• Account (only limited info is needed, mostly name and currency)
• Category
• Tag

Payee is typically bigger, but it can also be pre-fetched (usually only the name is needed).

Other info can be fetched together with Transaction records, with some kind of join queries.

The pre-fetched data can be stored at the level of Transaction VM. When Transaction records are requested from List View, the VM can combine selected data together with pre-fetched data, in order to present a convenient data structure to the View. Details that are not needed by List View can be skipped, or even not fetched at all from the database.

[guanlisheng]

yup, this piece is complex, no pattern like a model and repo, and depending on how models are designed and used.

There is a super simplified one InsightsViewModel, the goal is to solve multiple models on multiple Repositories, and keep data refreshed in time.

[georgeef]

An efficient storage (cache) of Currency formats in DataManager is implemented in #63. Only a limited (typically small) set of currencies is stored with reduced Data (only the formatting information, which is needed most often).

Account, Category, Payee are used quite often and can be similarly stored in DataManager, with reduced Data for better efficiency. Less often needed information can be loaded on demand, as it is currently implemented in List Views.