Gripes with using ingredient amounts

[fleshgolem]

So, I've been slowly adding ingredient amounts to all of my recipes and the experience is honestly far from smooth, so I thought i'd list my gripes here to see which of these could be considered bugs and easy to fix, which are more complicated and what is maybe working as intended

• The flow to even add this is kind of weird, but I am pretty sure that is just firmly a bug and already added an issue [v1.0.0b] - Annoyance in adding Foods/Amount to recipes, ingredients disappear at first #2183
• Foods are listed in some indiscernible order everywhere and there really is no reason for this. Yeah you always have a search bar but they still should be alphabetical to begin with
• The NL parser works like total ass for german, but thats probably nothing that can be dealt with easily
• Working with foods/amounts that are slightly differently named is quite annoying (I know an issue for that exists already at [v1.0.0b] [Task] - Support for Plural and Alternate Names for Ingredients and Units #1242)
  • However I see no reason why the parser doesn't add least match everything case-insensitive to begin with. That should probably be easier to do for a start and already get quite a bit of issues out of the way
• If you ever entered something wrongly and hit enter, it is quite cumbersome to get that wrong thing out of the DB again. As far as I see this is only possible on the "Manage Data" page, which is really not that easy to find, if you dont already know about it. Even if you do, navigating there anytime this happens (which it does to me at least quite a bit) is still a bit of a hassle
• There are a few ways to get duplicates into the system and IMO this really shouldnt be allowed ever. Catching this should also be done in a case-insensitive way
  • The seed function is quite useless when you have already started, because - while it warns about this upfront - I will still have to hunt for duplicates after I use it and that shouldnt be necessary
• Another reason why I wont use the seed function is, that the search page will then list all those 200 foods, even if I never use them anywhere. This filter should probably be limited to just foods that are actually in use in any recipe

Feel free to let me know what y'all think about these points. If we're in agreement that these are issues, I could make tasks of those ones specifically

[hay-kot]

The flow to even add this is kind of weird, but I am pretty sure that is just firmly a bug and already added an issue

For sure a bug, though I can't replicate it.

Foods are listed in some indiscernible order everywhere and there really is no reason for this. Yeah you always have a search bar but they still should be alphabetical to begin with

Definitely Not Intended

The NL parser works like total ass for german, but thats probably nothing that can be dealt with easily

Unless you manage to scrape together a data-set of 100,000+ parsed ingredients we're SOL on this one. You may have better luck using the brute force parsing method.

However I see no reason why the parser doesn't add least match everything case-insensitive to begin with.

I don't think you're talking about the parser here? The matching of what was parsed to what is existing is done entirely on the frontend with a loop and === comparison from what I remember. I'm sure there's some low hanging fruit there to improve the UX

If you ever entered something wrongly and hit enter, it is quite cumbersome to get that wrong thing out of the DB again. As far as I see this is only possible on the "Manage Data" page, which is really not that easy to find, if you dont already know about it. Even if you do, navigating there anytime this happens (which it does to me at least quite a bit) is still a bit of a hassle

I guess the alternative would be to create alternative CRUD interfaces that you could use somewhere else? I don't love the idea of having n amount of ways to do the same thing, but I'm open to suggestions.

There are a few ways to get duplicates into the system and IMO this really shouldnt be allowed ever. Catching this should also be done in a case-insensitive way

Agreed

The seed function is quite useless when you have already started, because - while it warns about this upfront - I will still have to hunt for duplicates after I use it and that shouldn't be necessary

I'd only ever expect you to run this on a fresh group, so I don't think that's a problem worth solving, but open to a PR that does some kind of deduplication

Another reason why I wont use the seed function is, that the search page will then list all those 200 foods, even if I never use them anywhere. This filter should probably be limited to just foods that are actually in use in any recipe

Yeah, adding some filtering on the backend to allow return on only foods with an associated recipe would be a great addition for the search page. Unrelated, but I'd also love to include the count of recipes returned for these types of things, but I haven't found a way to do this in SQLAlchemy without it yelling at me, it may be easier to just write the SQL query...

[fleshgolem]

The NL parser works like total ass for german, but thats probably nothing that can be dealt with easily

Unless you manage to scrape together a data-set of 100,000+ parsed ingredients we're SOL on this one. You may have better luck using the brute force parsing method.

Thats probably possible, but I'm not sure it is worth the effort. The brute parser works ok for the most part, so this really is the least important one of the bunch here for me personally

However I see no reason why the parser doesn't add least match everything case-insensitive to begin with.

I don't think you're talking about the parser here? The matching of what was parsed to what is existing is done entirely on the frontend with a loop and === comparison from what I remember. I'm sure there's some low hanging fruit there to improve the UX

Yeah, thats pretty much what I mean. If you have "tomatoes" in your database and a recipe lists "Tomatoes" you have to the matching manually even if this should be easily doable by the frontend. Im not sure how common this is with english recipes, but i do encounter it quite often

If you ever entered something wrongly and hit enter, it is quite cumbersome to get that wrong thing out of the DB again. As far as I see this is only possible on the "Manage Data" page, which is really not that easy to find, if you dont already know about it. Even if you do, navigating there anytime this happens (which it does to me at least quite a bit) is still a bit of a hassle

I guess the alternative would be to create alternative CRUD interfaces that you could use somewhere else? I don't love the idea of having n amount of ways to do the same thing, but I'm open to suggestions.

I don't really have any good solution for this either, I just wanted to open this one up for discussion to see if anyone maybe has

There are a few ways to get duplicates into the system and IMO this really shouldnt be allowed ever. Catching this should also be done in a case-insensitive way

Agreed

The seed function is quite useless when you have already started, because - while it warns about this upfront - I will still have to hunt for duplicates after I use it and that shouldn't be necessary

I'd only ever expect you to run this on a fresh group, so I don't think that's a problem worth solving, but open to a PR that does some kind of deduplication

Yeah agreed that you should do this on a fresh group, but this is quite the complex app and I'd say there is a good likelihood of people only finding this functionality after they already entered a bunch of recipes, but not an overwhelming amount to say that the food database is "complete"... I say this, because this is totally what happened to me
Anyway, if we would be doing deduplication anyway this probably shouldnt be too hard to implement, I think. I will try to write a Task on both of these points in general sometime soon

Another reason why I wont use the seed function is, that the search page will then list all those 200 foods, even if I never use them anywhere. This filter should probably be limited to just foods that are actually in use in any recipe

Yeah, adding some filtering on the backend to allow return on only foods with an associated recipe would be a great addition for the search page. Unrelated, but I'd also love to include the count of recipes returned for these types of things, but I haven't found a way to do this in SQLAlchemy without it yelling at me, it may be easier to just write the SQL query...

If you want to do this with a general property I am not sure on how to do this either, but if its just for a specific query you could do something like

select(IngredientFoodModel, func.count(RecipeModel))
  .join(IngredientFoodModel.ingredient)
  .join(RecipeIngredient.recipe)
  .group_by(IngredientFoodModel.id)

... or something similar, I just wrote this from the top of my head, but it should generally do the trick. This will of course retur tuples, so youd have to construct your return-Models manually but I wouldnt consider that an issue really

[Duchessy]

There are a few ways to get duplicates into the system and IMO this really shouldnt be allowed ever. Catching this should also be done in a case-insensitive way

Agreed

The seed function is quite useless when you have already started, because - while it warns about this upfront - I will still have to hunt for duplicates after I use it and that shouldn't be necessary

I'd only ever expect you to run this on a fresh group, so I don't think that's a problem worth solving, but open to a PR that does some kind of deduplication

Yeah agreed that you should do this on a fresh group, but this is quite the complex app and I'd say there is a good likelihood of people only finding this functionality after they already entered a bunch of recipes, but not an overwhelming amount to say that the food database is "complete"... I say this, because this is totally what happened to me

Exactly this happend to me too. So I also had to manually hunt for duplicates (Seeding with german even gives you duplicates directly from the beginning e.g. several duplicates for "Paprika").

[michael-genson]

Pretty sure all of these issues have since been addressed. Happy to keep this open if I'm wrong