In this workflow, when I use the same key for more than one song, it only adds that key into the list once. I would like for it to be able to add the same item to the same list more than once. Is that Possible
you have to separate your data more, if you want duplicates.
I had this problem with a messaging system, i would type hello, then hello again, it would only create the first message.
To remedy this i create a separate data type ‘message text’ and attach that text to my data type message which has ‘sender’ ‘between’ (list of users) etc etc.
Hope that helps
‘Set list’ can be a workaround sometimes when the list contains duplicates
The correct way to do this is to create a Message. A message from one user to another is not a text. A message should be a Message – a unique object. A Message then has a field for its Content (that is a text) and then it has a Creator (automagically – a field of User type of course), a Created Date, a Modified Date and a unique ID. The Message would also have a Recipient (again, of type User) or (depending upon if you want to support multi-user conversations) a Recipient List (a List of type User).
[Edit: the fields above are – obviously – not exhuastive. A Message could have much more metadata within it – e.g., a flag for “Read” (a field of boolean type), a flag or indicator for “Priority”, etc. etc.
Edit 2: @anon65040322, I realize you solved your problem in this way, was just explicating this a bit more. I am continually puzzled why Bubble users are always trying to do things with primitive data types rather than with Things. It’s almost like they don’t do the tutorial lessons or something. ]
A conversation should be represented as a Message Thread (you can pick any name you choose for this, of course, but this would be my pick). A Message Thread can simply be a List of Message type.
(When you do this, you see, you can very easily do things like know all of the participants in the thread: This is just some_Message_Thread’s Messages’s Creator (which resolves to a list of User type – all Users who created a message in the thread). If you wanted to consider Recipients who might never respond as “participants”, then its some_Message_Thread’s Message’s Creator :merged with some_Message_Thread’s Recipients or some such. The number of messages in the thread is just some_Message_Thread’s:count, etc.)
tl;dr: You’re probably doin’ it rong.
works perfectly how i have it. im not doing anything wrong, you are making some assumptions.
i just gave a very rudimentary example, see i have it set up like you describe
I pointed that out in my edit, @anon65040322. I wasn’t meaning to imply that your suggestion was incorrect: I was attempting to explicate this a bit more.
The main point being that – most of the time – when one runs into the issue of “ah, these things in this list are no longer unique and I need them to be unique,” one has discovered an error (or maybe let’s call it an unforeseen need) in one’s data model. (Luckily, Bubble makes this easy to fix as we can always create some new type of Thing to bundle up the necessary fields that we want to allow as duplicate items.)
ok… and i never did the lessons
I was told creating “things” is slower than adding to fields of an existing thing.
I have an invoicing system that lets users create an invoice with one of 15 services and a space to add a unique “Add-on” service (enter any name and price)
If I create an “Add-on” thing every time someone adds one to an invoice, it won’t be long until my database had tens of thousands of “Add-on” objects (or things) that will never be used again. Does this run the risk of making my site slower?
I feared it would so I made the “Add-on name” and “Add-on price” to fields on my invoice object (as lists)… however I run into the exact same problem of not being able to create duplicates (if I add two extra uniques that have the same price it won’t add the 2nd one)
Should I revert back to making Add-ons things?