Closed rpazyaquian closed 10 years ago
Actually, no, what am I doing? There's a better way to do this: a Cuisine model.
Cuisine:
A Cuisine can be validated, and it becomes clear which recently eaten Cuisine came before another: sort them by creation date.
So, it's more like this:
:italian
for the cuisine type.:italian
.@user.cuisines
as its data. Repeat until the User has ten Cuisines.This also allows me to retrieve a list of recently eaten Cuisines by just calling @user.cuisines
and creating a new one by calling @user.cuisines.create
.
The one thing that bugs me is that it saves more data to the database than is actually needed(?), which gives me pause. But, it's probably the more Rails-y way to do it, anyway.
Users now have many Meals, the oldest of which is destroyed upon creation of a new one if there are already 10 Meals in the history.
In contemplating how to get the app to predict a "new" cuisine, I've come to this conclusion: at the very least, I need some way of recording the user's meal history. I propose adding a
meal_history
attribute to the User Model that looks something like this:meal_history = [:italian, :chinese, :american, :moroccan]
Yep, it's an array. Specifically, it's an array of the 10 most recent cuisine types eaten by the user. A
meal_history
is initially empty, and a symbol of the most recent cuisine ispush
ed to it every time the user asks for a recommendation. If no more symbols can fit, the array isshift
ed in order to pop off the top of the queue. This allows the application to choose based specifically on the 10 most recent cuisines.meal_history
will be stored in the database as a string, by converting the symbols to strings and joining them with a comma,
. It will be retrieved from the database by splitting the string by comma, and converting each string to symbol.I have a feeling this is not a good idea, but it's a start.