Forum Academy Marketplace Showcase Pricing Features

Add same element multiple times into a list


I would like to add the same element twice into a list.

Example :

I have a database of element : element A, element B, element C, …

And I am trying to create a list of elements.

Example :

Element A
Element B
Element B
Element C

As far as I understand, we cannot add the same element twice into a list (here element B).

I created a key field for my data type element and a WF which attributes a random string key to each element.

The WF is working but it doesn’t change the unique ID of my element so I still can’t add element B more than once into my list.

Do you know how to solve this issue ?

Hi Newman…

Yeah… you can’t have two elements with the same uniq_id in your list.

There are other solutions to this problem and I can try to help you. But first, in order to help you in the proper way, could you share more details about what you are trying to accomplish?


To give you more context.

I have a mutual database of exercice for all my users in a database “exercice”.

I have a database of sequences with a field list of exercices.

An user can create its own sequence based on the mutual database of exercice.

Everything it is working well except when an user is trying to add multiple times the same exercice to its sequence of exercice.
It doesn’t work because you can’t add twice the same element into a list.

I hope it is clear enough.

Oh. Yeah. Understood.

So… Instead of store a list of exercises, start to store a list of text.

In this list, you will add the exercise’s uniq_id + random sequence of 6 characters.

That’s it.

So imagine a exercise with an uniq_id equals to xxxxxxx. If you keep adding it into your list you will have something like this:

  • xxxxxxxda23sd
  • xxxxxxx234dr5
  • xxxxxxx234gs4
  • xxxxxxx123452

And when you want to show the exercise, just do a “Search for” for the the list item without the 6 last characters.

You can do this using the commando “”:truncated to":

Hi Newman,

@rpetribu’s suggestion will solve your immediate need. However, if you’re looking for a more flexible and longer-term solution, I would encourage you to reconsider your data structure.

If you think about it, your Exercise data type - i.e. the DB table representing the list of exercises - is really a master list of exercise types. It does not represent a specific bout or session performed by a user. Thus, you might consider adding an Exercise Bout data type as well as a Workout data type - a workout being linked to a user and comprised of a list of exercise bouts.

Thus, your data structure might look something like the following:

  • Exercise

    • Name (type text)
    • Description (type text)
  • Exercise Bout

    • Exercise (type Exercise)
    • Sequence (type number)
  • Workout

    • Client (type User)
    • Bouts (type List of Exercise Bouts)

Of course, this is just one schema possibility, but the point is that you need another structure to hold both the exercise type and the sequence. This approach keeps things more modular, enabling multiple bouts of the same exercise per workout as well as making the app easier to maintain as it evolves. For instance, you might at some point want to add a Duration field to the Exercise Bout data type, which would also enable you to get the total workout duration simply by summing the duration of the exercise bouts comprising it.

Anyway, just a few things to consider. Good luck!

Thank you both for your answer @rpetribu & @sudsy !

@sudsy I thought about doing it this way but I was wondering if it was a good option.

In the first option I only have one database of mutual exercice which are added/deleted from different lists so it is a very light DB.

With you suggestion, I need to create an exercice bout for each added exercice which duplicates many times a single exercice.

I am curious to have you thought on that.

Sure, but you’ll need to do that regardless of which data schema approach you take. IOW, you’ll need to “represent” an exercise bout somehow, whether it’s a string of text or a more modular approach using a dedicated data type like I described.

Generally speaking, your Bubble data types should map to real-world “things”, whether they’re physical or conceptual.

No, items in the master list of exercises are not duplicated. Rather, multiple references which “point to” those exercises are created.

With proper design, performance will not be an issue if that’s your concern. In fact, I would actually revise my proposed schema to include a link to the user (field of type User) in the Exercise Bout data type as well.

That would allow for some nifty summary statistics and visualizations (graphs and charts) over time, especially if you track duration for each bout of exercise.

Of course, none of this is an issue if you know exactly how your app will be used and you’re confident it will never need to evolve or adapt, but a modular approach lends itself better to revision and enhancement as your business evolves and data needs change.

Good luck!

1 Like

Hello Steeve,

Got it, thank you for your detailed answer.

What I get from your insights is it is going to be more flexible and easier to maintain in the long run with this option (which is very important !)

1 Like