My app requires a unique reference number, or ID, for each submission by the user.
At the moment, I am using “Do a search… :count” and “Do a search for ID… :last item+1” to list the submissions in numerical order, but I am finding this is causing delays in the process and I want to make it faster.
Anyone know any better ways to achieve this?
I am aware of the unique reference number that Bubble allocates to each submission, and I have toyed around using the last 6 or so digits as our URN/ID, but I also require this reference to be used for our invoices with continuity.
How about using a single search and using :max to get the largest value and then +1?
If that doesn’t work or you run into race conditions, I recently built a plugin that is for unique Id fields. Allows you to create a field and track unique Id keys outside of bubble using database locking to prevent dupes.
Let me know if interested and I’ll packages it up for public use.
All objects in your database already have unique ID. Go examine the data tab and also when you’re building an expression, note there is a unique ID. Like:
User’s unique ID
Photo’s unique ID
Listing’s unique ID
In your case, you could potentially use a “seed” (for lack of a better technical name) record in the database.
Specifically, you create a table which will only store one record. This record will be used for holding a very specific value or two. (Ie. a number-based field which stores the total count of invoices created).
As part of your workflow, you can “Do a search” for the seed record’s invoice count. Then, you can have a workflow that increments the search count by 1 for each invoice created. Then, the create a new thing (Invoice) would reference that item’s invoice count as you assign a number.
From Bubble’s operations standpoint, you should be OK to do this without fear of the data being updated properly (see this post).
That’s a cool solution, I’m sure I’ll use that somewhere! But I don’t think it meets the OP needs, which include numerical order sorting along with continuity with invoice number display…or does it?
I think you’re on the right track making the differentiation between contained within Bubble and using an API workflow (via Postman).
From what I understand, I believe Bubble enforces some sort of queuing for CRUD operations contained within Bubble. But the same may not apply to a API workflow triggered externally.
I’m wondering if it makes a difference - are you using POST or PUT with your API workflow? @Keith, see that you’re typing…so I’ll let you respond and clarify my thinking here.
Yeah, @mikescullion’s ask is a pretty big one, actually. He’s correct that, in order to make a thing have an increasing serial number (which is essentially what is being described here), Bubble has to count all the items before assigning that serial number. And that can’t really be sped up.
There’s also the issue of collisions. I’m not sure how likely this is, but it does seem that it’s possible that two things could be created (for example) at a time when the current count of things is n and so both might get assigned serial number n+1.
This just seems really problematic at the Bubble programming layer (where “we” are) and this kind of sounds like a request for enhancement (i.e., could Bubble give data types an optional serial number? – such number would be assigned at creation time and handled at the same level where uids are generated and, as such, collision issues etc could be handled properly).
In terms of the “speed” issue: One way that might help @mikescullion: Lets say that a new thing is being created. That thing could be created and the serial number/custom ID thing could be created LATER so that the user can get on with data entry.
The way to do that would be for workflow step to just Create the New Thing and then call a scheduled API workflow (the schedule time can be set for “now” - i.e., current date/time) to do the serial number steps (check current count of things, set that field to count+1).
To the user, what this would look like is, they (for example) get directed to an invoice input page (or whatever) and that page has a “serial number” field and – when they first arrive on the page that field might look blank, but then shortly after it would magically populate with the number as soon as its been generated.
So, none of the user-facing workflow seems slowed down. In fact, in practice one might find that the serial number never or almost never looks empty to the user. It’s one of those “try it and see” things…
Doesn’t seem like internal works either. If I schedule an api workflow on a list from within bubble, and then trigger that with a couple browser windows open, I still get dupes. This is why I ended up making a plugin and tracking on the outside so I could use a database to control it all. It adds a second because it is an external call, but it works.
What you’re proposing, @dan1 feels like the right way to do this. It does look like (from @mebeingken’s experiment) that there’s a potential collision issue in that externally-triggered API workflow case, but internally as you point out it “shouldn’t” be an issue…
The “speed” issue pointed out in the original post is kind of orthogonal to the uniqueness/collision avoidance issue (which it kinda seems one doesn’t actually need to worry about [edit: maybe one does, based on @mebeingken’s follow-up!), and I proposed a solution in my earlier reply.
)