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?
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.
@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.
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.
