Simply add the numeric code you would like to have like this, hope it helps you 
1 Like
Thanks a lot @hanifyaskur,
It works! I thought it would more complicated.
Have a good day and thanks also to @morgan and @keith for the explanation.
Thank you so much man 
As I can see from here: Bubble.io Tutorial: Database Trigger Events - YouTube backend workflows are only available in professional plan and above. Is there any way to implement this solution in Free or Personal plans as we still prepare the project for the client ?
I’m sorry to resurrect an old topic, but going through everything, something keeps bugging me:
If you are doing a search for all orders with a creation date ≤ This Order’s Creation Date, presumably, the ‘count’ of these records, will include ‘This Order’… why then would we need to add a +1 at the end?
In this context, the +1 just creates a situation where the Serial Number is always one number higher than the actual number of records, right? Most probably not a big deal, either way. I’d just like to confirm if having the +1 is ‘redundant’.
Will appreciate any opinions.
Another thing:
Is there a reason why this should be done in the Backend Workflows, and not as part of the normal workflow process?
I generally need the unique IDs created as part of the ‘create a new thing’ process, so I can use that ID in a reference in the next part of the workflow. I can’t make this reference, when the unique ID’s creation takes place in a backend workflow.
I don’t think there’s a reliable way to implement this through regular workflow. Unless you’re sending data to the server one-by-one (and not expecting other user submits the same “thing” to the server in same time).
I never done this, but I suggest you to try the same formula “Search for x:make static:count +1”, use it as an input field prior to the data submission.
If it works, then hopefully will also answer @obvolut question. Since it will enable us to utilize the “IDs” through regular workflow as well.
It works when you do it as part of a regular workflow. I have it set up and running. Only thing is, like you mentioned: how will Bubble handle it if more than one user happens to ‘create a new thing’ at the very same second? Does anyone have any insight as to whether this is something that could realistically happen?
On the other hand, to get around this potential ‘loophole’, I’m considering switching things around a bit:
-
Taking the process explained above, to create a unique sequential number, but setting that number as a slug. Since, slugs automatically check for duplicates, and append a -1, -2, -3, etc etc, where necessary.
-
Then setting the slug’s value, as the thing’s ID.
Might not make sense for a lot of use cases, but in my use case, I’m creating a bunch of records, and their most important ‘unique’ feature, are their IDs. The records also use the IDs as their slug.
Having a few records here and there, that look like 10001-1, 10001-2… I could probably live with that. But I’d really rather not have to do this…
And Backend Workflows work on Personal Plans… unless something’s changed and I’m now on a ‘legacy’ plan of sorts… I only started paying in August 2020… I don’t think the terms & conditions of the Personal Plan have changed in that time…
Hi
I created a trigger custom event on the backend and gave it an event name
When I try to trigger that event in the workflow, the event name does not show in the trigger custom event name dropdown.
How do I trigger this event in the workflow?
How does this solution scale? For instance, if there are 100,000 orders that it’s searching over wouldn’t a count take a while?
@pgjerde My understanding is that the very first time you search for something then Bubble might take a moment but after that it creates an index (or whatever the terminology is) that allows it to search that same thing much faster in the future. So, even if there are 100,000 orders then getting a count of that is lightning fast.
I want to follow up to my last comment in reply to @pgjerde about the speed of a search for the purpose of just doing a count of the list.
I’ve been doing some testing and I discovered that the “:make static” function makes the database trigger take FOREVER. Well, okay, not forever but much longer than desired and assuming it successfully completes the search in the first place.
If I remove the “:make static” and just do a search and a “:count” then it’s lightning fast. I was testing on a database with over 116,000 orders and am trying to consistently generate a sequential order # each time.
Even when adding constraints on the search so that it’s counting less than 7k orders, placing “:make static” on the search caused a noticeable delay on the database trigger method described by @morgan.
What is it about the “:make static” function that would cause such a delay? It must be doing something per item in the list because the delay grew when the list was longer.
1 Like
The documentation alludes to converting (copying?) each item in the list. That could come with a performance penalty if it is doing some type of deep copy.
Thanks for the follow up!
I would use a Firebase atomic counter to complete this task if it was me
Hi All,
I needed to assign a sequential order number to each order, thought I’d share what I did in the hope it may help some of you.
-
Create your database structure for the order and add a number field. You can call it order number or whatever you like.
-
Create an order within the database with the order number as the start of the sequence . It can be any number but for simplicity lets start with the number one.
-
When an order is placed, depending on your work flow, either create or update the order number by using the following logic:
Create New Order
Order Number = Search for Orders [ Sort By ID] [Descending: Yes] :firstitem + 1
The above logic will find the most recent order number, add 1 to it and crate a new order with that number. Hope this helps. Happy to answer questions.
1 Like
Helpful – However this post is deeper than that. The method you described is what they were using… but the meat here is you can still run into conflicts and duplicates. That’s where this becomes incredibly difficult.
If 10 people are adding something to the database at near the same time, you could have the same number showing up for a few of those 10 people. It’s because the “Search for Orders” part takes some time to calculate… It isn’t instant. If the Search takes 100 ms and adding process as a whole is completed in 50 ms, you run into a situation where 2 people out of the 10 are getting the SAME number when they search (because the Search hasn’t caught up to the fact that there was a new order coming in AS the search was being run).
I’ve run into this myself with some of my database tables being 5000+ entries and 10’s of people trying to add posts.
Just food for thought for larger, more demanding applications. In my software development company, we run into this issue with PHP/MySQL as well, so this isn’t a “Bubble specific” issue, in my opinion, unless you consider Bubbles operations are a bit slower than custom written code.
Yes but you can generate a unique record/number that is auto-incrementing in mysql automatically without having to worry about any of this. Bubble should allow the same.
Good point!
1 Like
Old topic but important discussion 
Instead of doing Search for orders:make static: Count
Could we do:
Do search for orders:make static each order number:max + 1 ?
What do you thing @morgan ?