Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store information about feeding timers at the start #11

Open
btoconnor opened this issue Nov 7, 2022 · 1 comment
Open

Store information about feeding timers at the start #11

btoconnor opened this issue Nov 7, 2022 · 1 comment

Comments

@btoconnor
Copy link
Contributor

btoconnor commented Nov 7, 2022

Storing information about the timer when it's created I think would help alleviate some of the back and forth with Alexa when completing timers, most notably the feeding timer.

Ie, it would be nice to say:

Alexa, ask Baby Buddy to start a bottle feeding [for name]

and not have to specify the method when the feeding is concluded, since we specified at the start that it was a bottle feeding.

Similarly, something like:

Alexa, ask Baby Buddy to start a left breast feeding [for name]

would also allow us to fill in some of the details without resorting to yes / no / multiple choices in a row at the conclusion.

I am fairly certain this would require changes to be made on the core Baby Buddy application, and there are a lot of ways to go about that which would need to be discussed. However, I wanted to gauge interest in doing that up front before going down too many paths on how to achieve this[1]. I am pretty sure I can take on the work for this if the concept itself is desired, depending on the implementation method of course

1 - My first instinct would be to just store some structured metadata in a denormalized column on the timer - like a JSON structure that stores stuff like type (feeding, tummy time, sleep), and any other data about the type of timer. In theory you can accomplish this stuff with multi table / single table inheritance but that gets silly complicated for a few attributes. Django itself doesn't seem to like single table inheritance as a concept (which, I guess is a fine opinion, but the feature is great for stuff like this). Storing a little JSON structure could get unwieldy, but that's one of those "cross the bridge when you get there" kind of things for me. "It's as complicated as you allow it to be" comes to mind.

@cdubz
Copy link
Member

cdubz commented Nov 7, 2022

Interesting concept... the idea of having a general purpose "context" field associated with the timer seems reasonable to me. It could just be a JSONField type on the Timer model and could be left to third-party implementations for now. I'm on board.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants