Search on a List?

[tadeu.msv]

In a storage table … if i have a list of ingredients along with a list of prices and a market data type… How can i make a repeating group showing the ingredients and prices (correctly aligned) sorted by the correct markets ?

Do a search for storage → list of ingredients ( no way to sort by market)
This seems to be nearly impossible as i can’t sort items using a data type.

[AdamT]

Hello,

AFAIK Bubble does not let you sort by related record (unless this has been a recent addition). It seems like what is needed here is sort by thing’s things’s property.

I’ve run into this before and the workaround can be a little ugly - I created backend workflows that denormalized the name of the market (in this case) to your ingredients table as a text field so that you can use that text field to sort. It has a delay on it so it won’t work realtime with changes very well, but it should work. You don’t necessarily need to use a backend workflow for it either, you could use a frontend workflow whenever ingredients are created or edited.

This isn’t really ideal and seems like a pretty bad database practice… but it sorta works. There’s a post out there somewhere with the devs with some reasons why this isn’t available, but I wasn’t able to find just now.

Maybe someone else out there will know a better trick for this.

Hope this helps a bit,

Adam

[tadeu.msv]

Thank you for the reply. I am scratching my head around this and it’s crazy to think that there is no way to relate a list of objects that is inside a storage table that i created. In this case, the ingredients may have different prices based on the market that they are and there is no way to make a connection and display that on a repeating group.

[AdamT]

Ah, maybe I misunderstood you, I thought it was specifically about sorting the repeating group, but if it is about storing unique prices for each ingredient at each market you might want to consider a many-to-many-relationship like this?:

Records:

1. Ingredient
2. Market
3. Market-ingredients
   – Market property w/ link to market record
   – Ingredient property w/ link to ingredient record
   – Store the price here as a property.

This way you can create combinations of all the ingredients at all the markets with their prices.

You can set up your repeating group to show market-ingredients:

• If you only want to see the ingredients and their prices at one market then you can filter by that market.
  OR
• If you only want to see one ingredient and all the markets where it is available with prices then you can filter by the ingredient.

Maybe this is what is needed?

[tadeu.msv]

You are right. This is what i have made to make it work (for now ?) , but i got worried that the use of an absurd amount of workflows (on a list) to fill line by line (creating one by one instead of having a full list stored) would kill me in the long run.

In the current model it would be just like this one :

1. Ingredient
2. Market
3. Market-ingredients (or Report / Storage info )
   – Market property w/ link to market record
   – Ingredient property w/ link to ingredient record
   – Store the price here as a property.

The result will be :

   **Market-ingredients (Report table)**

                        Market GoodX    |    Cinnamon roll   |     $16
                        Market GoodX    |    Cinnamon           |     $10
                        Market GoodX    |    Sauce                    |     $7

But i thought that … what if … making a lists would help me reduce the workflows:

1. Ingredient
2. Market
3. Market-ingredients (or Report / Storage info )
   – Market property w/ link to market record
   – Ingredient LIST property w/ link to ingredient record
   – Store the price LIST here as a property.

But i think it will be a nightmare to work with data inside a list to make a dashboard (unless i use power bi or google data studio) to organize the data to make analytics.

[AdamT]

I would probably agree that using the lists might cause issues later, even if it saves on a few workflows now. Using the combination record for the many-to-many should be a pretty reliable structure.