Add management for inventory of "what i have at home"

[timo-reymann]

As a user i want to keep track of what i have at home so i can optimize my grocery shopping and reduce my costs.

[timo-reymann]

General Ideas for implementation

Accountants don't use erasers

• use a journal of changes instead of aggregating
• having a change-based system makes it easier to sync

Utilize CouchDB views

• CouchDB provides a convenient way to aggregate data directly in a view
• PouchDB is fully consistent, besides execution happens locally instead of server-side

Caveats

• Compaction for CouchDB should be enabled to make sure views dont take up too much space after time -> add that to config directly
• large journal might result in performance issues -> benchmark and create potential solutions like cleanup all stock information summing up to 0

[timo-reymann]

Proof of Concept for view aggregation with reduce: timo-reymann/poc-couchdb-view-reduce

Also with larger number of items seems to be no problem for now, as the application continues to mature this might come up again. But for the foreseeable future this should work just fine.

[timo-reymann]

TODOs:

• Create data structure for inventory :heavy_check_mark:
• Create view document once data structure for inventory is ready :heavy_check_mark:
• Add helper to query view :heavy_check_mark:
• Add inventory change when marking items as done and removing on undo :heavy_check_mark:
• Design UI to display data
• Allow manual modification of inventory

[timo-reymann]

Draft for inventory logic & data structure

Database structure

Represented as table

ingredientKey	changeAmount	unit
sugar	(+)100	g
sugar	-100	g
sugar	(+)1	pkg
sugar	(+)10	g
salt	(+)10	g

Aggregated in view

ingredientSpec	amount
[sugar, g]	10
[sugar, pkg]	1
[salt, g]	10

Display in application

sugar   10 g
    1 pkg
salt    10 g

Recipe logic

Given the following recipe ingredient list:

• 10 g salt
• 100 g sugar

Where one ingredient stock is rated between and 0 and 1, where 1 is the total amount, so we can see the utilization with stock we can potentially reach.

For salt:

10g salt = 1 
in stock = 10g

ingredient score is 1

For sugar:

100 g sugar = 1
10 g  sugar = 0.1
1 pkg sugar = 0.3 # maintain the factor based on unit, this is just an estimation and will adopt over time

ingredient score is 0.4

So when a recipe has a score of 1 for all ingredients we can be certain that we can do the ingredient with all in stock, in this case the median for the recipe is 0.7.

In this case 0.7 indicates we are likely to be able to do the recipe.

If the score goes under a certain treshold to be tested, for the beginning go with (< 0.5) the recipe is defintely not possible to do.

This way the exact matches are a easy match. For all conversions, uncertainites between units/measures there is an estimation which is already a certain degree of automation.

Discovery Results

• giving e.g. pack a hard conversion factor will mess things up, so for now will just be ignored for conversion
• factor based totally makes sense still, based on actual units, for "unconvertible units", e.g. between pack and grams wil have to find another way, will be ignored for now

[timo-reymann]

Refactored initial idea for shopping lists: Now instead of having a dedicated journal entry for these, just consider the shopping list item instead, the item is also not deleted currently when shopping list is deleted. This way there is always consistent stock info for shopping list items.

For other changes, the journal is also considered.

In the future, there needs to be a compaction of shopping list items to keep the db small, will be left open for now to get the app up and running. Could also be a good idea to only show the last x days for bought ingredients