lukeforehand / aletrader Goto Github PK

Entity fields such as brewery, beer name, location etc need to be normalized in order to perform term searches or facets.

These fields should periodically be reviewed scrubbed and updated using a definitive source. This source could be a cached relational database.

Entering items into the cellar is the main workflow
Enter Cellar Item Storyboard

Add cellar item:

• scan UPC code to find beer details OR
• search for beer details
• if UPC lookup fails, resort to search
• if search fails, user can enter new beer details for us

Add new beer:

• add beer details
• save

Search results:

• either a UPC code scan, search, or add new beer was successful
• choose quantity of items and proceed to confirmation OR
• choose to label bottles and scan QR labels

Scan QR labels:

• user labels each unlabeled bottle with a QR code
• QR codes will be unique so user can print several pages of labels in the beginning to use
• scan QR code for each bottle in the package
• proceed to confirmation

Add item Confirmation:

• verify entry details and save
• if a UPC was scanned and a different or new beer was associated, record this in our system

• relationship will be one user to many cellar items. cellar items will be globally unique.

fields:

• username
• avatar link
• city
• state
• country
• club (optional)

• start with beer
• use json for schema

fields:

• UUID
• owner / user (globally unique)
• name (globally unique)
• commercial product (boolean)
• brewery (required if commercial)
• cellar date
• photo link
• container / qty
• cellar location (optional, where is this item located in the cellar, i.e. shelf #, basement, or geo)
• description
• recipe (optional)
• tasting reviews []
  • age

fields that are globally unique need to pass validation before being indexed, to ensure the value is either scrubbed to fit into an existing value or is known to be a new value (we will store unique value dictionaries in a persistent cache)

although cellar items are the primary entity, we may want to use the parent-child feature of elasticsearch to model the user to cellar item relationship, where the user would be the parent and would contain unique cellar items as children. This would provide flexibility to modify cellar items without modifying the user, and detach cellar items from user if necessary, but still allow for filtering search results using this user->cellar item relationship.

A user will likely select multiple bottles for tasting, so allow them to build a tasting queue from scanning QR labels. They can refer to this queue to rate the tasting of each beer, this event should record the age of the item.

This ability to build a queue will help the situation where a user only drinks a single bottle from a case, where the QR label is associated with an entire case and not just the bottle.

We need a way to know when a beer is gone, or when a case is gone, in order to stop reporting. Maybe a qty field on item is necessary, meaning you can store multiple bottles (a case) under a single QR code.

A cellar report will provide an inventory and aging information on a monthly period, useful to remind user of quantity and age of items. Could include previous personal reviews as well as other users reviews of similar items, with age comparisons to help user decide when items are best tasted and/or which items to taste next. Keeps users engaged.

If we can extract this information in an easy and consistent way, it will help build our brewery / beer database, and make it easier to enter items into cellar.