Shot record metadata fields #66

@ebengoechea would final_beverage_type fit on pre-shot workflow data? Or do you specifically want it on after-shot data, because of "happy little accidents", where people decide to make a cappuccino, but it comes out a flat white instead?

Or maybe, have a "intended_beverage_type" (pre) and optionally "final_beverage_type" (post) can override it.

@tadelv Primary workflow would be defining the intention, thus normally before the shot. But it should be modifiable after the shot is made, e.g. in case the user forgot to define it and wants to amend it. Not convinced 2 different variables are needed (intention and reality), can be just one.

@ebengoechea the term 'workflow' in StreamlineBridge loosely represents the DYE favorite. Therefore I think it would make sense to have a pre-shot version and an after-shot version, both contained in the ShotRecord. One for referencing what was actually made and drunk - and one for referencing what was the intended beverage, as well as an option of repeating it.
Though now that I put that in words, I see your point. If you started with espresso, that turned into a cappuccino, you would want to repeat the cappuccino, not the espresso.

I am currently working on a schema draft, which is why I'm posing these questions here. I'll let you know when a branch is available for closer inspection

@vid Auto-favorites will need to group according to only one of the 2 variables, if there are 2 that should be the after-shot version.

The before- and after-shot logic could apply, on the limit, to many other metadata that is entered manually by the user, like equipment fields. Do you need that added complexity? I'm not convinced.

Dose_out vs drink_yield is also a before and after case, but I think it's different because dose_out affects the app (stop-at-weight) and drink_yield possibly after-shot calculations, so they have to be different.

I agree, there is no need for extra complexity @ebengoechea .
At least from the repeatability perspective - what was done is what matters. And if it was good, you want to repeat that, not repeat the intent. - At least that's how I explain it

So Shot on Visualizer sort of organically developed and we landed on "old" / current Decent info plus some extra Visualizer stuff: https://github.com/miharekar/visualizer/blob/main/app/models/shot/jsonable.rb

After quick glance that would be: tags, roaster id, coffee bag id, user name, profile url, image url.

Then there's the big one: metadata. This one is a simple hash of key-value pairs, where keys are user defined (each user defines their own keys) and values are strings. It's quite naive, but it works. It's also only available to premium users, or people who self-host Visualizer.

Then there's Beanconqueror. It significantly predates Visualizer and it wasn't always integrated with it. So it has its own "metadata" and lots of it. Not that many BQ users upload to Visualizer so there was never any consolidation requests or anything like that, so the way it currently works I just simply store the entirety of its metadata (which they store in multiple hashes of key-value pairs) and I do not parse it (outside of decent compatible fields) I simply iterate over it when displaying a shot: https://github.com/miharekar/visualizer/blob/1a5dd124934a49a286d4100b31d5aee47238f65c/app/views/shots/_details.html.erb#L134-L142

So here you can decide what to do: either have a new key-values pair fields like Beanconqueror or go deeper and specify everything and then improve parsing on Visualizer to store this in a more structured way. Do keep in mind that this will then also require Airtable syncing changes and some users are very finicky about their airtables 😬

My experience thus far is that every user cares about different things and there is no consensus whatsoever 😅 That's why I went with completely arbitrary metadata and it has worked great so far.