I see. It intrigues me.
I will develop the plugin without the changing database design. If it
works, I'll send to you.
2012/2/8 Thomas Mills Hinkle <Thomas_Hinkle@...>
> It would be pretty daunting to overhaul the DB structure. It would be more
> conventional to use an integer for "ingkey" which is currently text and
> then have yet another table that linked the "ingkey" (conventionalized
> ingredient name) and number, but that would add another layer of joins and
> complexity without necessarily bringing any substantial efficiency gains.
> Storing only an "ingredient id" and "recipe id" per ingredient doesn't
> work because ingredient "text" in recipes often includes recipe-specific,
> useful information, such as preparation information and so on. You have to
> remember that Gourmet is designed to make it as easy as possible to work
> with actual recipes, rather than being designed to turn recipes into the
> kind of database a programmer would necessarily fashion from scratch. The
> way it works out, someone who doesn't care about nutritional information or
> particularly care about getting their shopping lists perfect can use
> Gourmet without ever having to think about the "ingkey" (standardized
> ingredient name). Gourmet then adds the "ingkey" as a layer so that these
> more data-centric tasks (nutritional info, good shopping lists, etc.) can
> be layered on over the standard, messy representations of recipes.
> So we end up having...
> - Info
> - ID
> Ingredients (your "Ingredients per recipe" tale)
> - Recipe ID
> - Amount
> - Unit
> - Description (name + prep info, etc.)
> - ingredient key (unique text identifier, used for shopping list and for
> nutritional information, etc. -- this may well end up being identical to
> the "description" text if the user doesn't want to bother improving it and
> in fact this is invisible to the user if they don't activate one of the
> plugins that makes use of it)
> Then, as equivalent to your "Ingredients" table, we have a couple of
> different tables
> Keylookup_table - this table actually just facilitates faster search when
> trying to match a new key to an ingredient. Note that the "count" here is
> part of a way of prioritizing search results -- it is possible for the same
> text to "key" to a different "ingkey" in different contexts -- this is
> because recipes are often imprecise and a user generating a shopping list
> may specify that they mean different things when two different recipes call
> for an ingredient like "pepper" or "flour."
> - text
> - ingkey
> - count
> - word
> - ingkey
> - count
> Nutritional Aliases
> - ingkey,
> - USDA ndbno (this links to all nutritional info)
> Not simple, I know, but I hope that makes some more sense of things.
> On Wed, Feb 8, 2012 at 1:12 PM, Patricia Dousseau <pdousseau@...:
>> I've found defaults file. Thanks.
>> What I mean about the tables:
>> A recipe can have many ingredients, and a ingredient can be in many
>> recipes. It would better if we have three tables:
>> - ingredients
>> - recipe
>> - ingredients_recipe
>> So we could have something like this:
>> So if we have a common ingredient, like salt, pepper, sugar, it will
>> appear only one time in ingredients table. It would be much better to
>> search recipes through ingredients, it wouldn't be redundant, it would
>> spend less storage space and tables would be normalized.
>> The way it is done gets really hard to get ingredients that are not
>> repeated, because ingredients_table has many instances of the same item.
>> Another thing I've found strange is that shopcatsorder doesn't have a
>> foreign key, like many other tables.
>> I can make another design for the tables, and try to implement. What do
>> you think? Do you think it would be too complicated to change the actual
>> design? Or would I have to change only the db.py?
>> Thanks, and sorry if I'm being much abusive.
>> 2012/2/7 Thomas Mills Hinkle <Thomas_Hinkle@...>
>>> On Tue, Feb 7, 2012 at 6:35 PM, Patricia Dousseau <pdousseau@...:
>>>> I downloaded Gourmet and I loved it, it has wonderful features! It's
>>>> helping me a lot, I'll use it as my official recipe book.
>>>> I wanted to help the project, so I downloaded the source code to take a
>>>> look. I'd like to imple Doubts about implementation ment a plugin to
>>>> list and set the price for ingredients, so that people could know the cost
>>>> of any given recipe. I ended up with some doubts, and I'd be very grateful
>>>> if you could help me:
>>>> - Is the default.py file used anywhere? I looked for references in the
>>>> code but I couldn't find anything.
>>> Yes, the defaults are used frequently -- look for import
>>> defaults.defaults just about anywhere in the code. The defaults directory
>>> is basically set up for localization that can not be done with
>>> standard/simple localization tools -- unit conversions, categories, common
>>> ingredients, etc. -- things that go beyond simple translation.
>>>> - Why aren't the recipe table and the ingredients table n:n? Very
>>>> common ingredientes like salt end up with numerous entries. I also found
>>>> strange that the the foreign key was placed in the ingredients table,
>>>> instead of the recipe table.
>>> I'm not sure what you mean, I'm afraid.
>>> There is a table for recipes, each row of which includes information
>>> about a recipe. Then there is a table for ingredients, each row of which
>>> includes information about a particular ingredient, including the recipe it
>>> is part of.
>>> For what you're working on, you'd want to create a new table which
>>> worked off of the ingkey and keyed it to a price. You can use the shopping
>>> code as a model, as that does the same thing (keying each ingkey to a
>>> shopping category).
>>>> Congratulations and thank you very much for making Gourmet available.
>>> No problem. Glad you're interested in playing around with it.
>>>> Have a great week,
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> Grecipe-manager-devel mailing list
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> Grecipe-manager-devel mailing list