"MaximumId + 1" to set userId is taking too long (+12k users)

I’ve been using “Maximum Id +1” (magic number feature) to define an Id in a user database. Because I have more than 12k users, this action is taking too much time.
Any idea how can I perform this task in a more efficient way?
I was wondering to store the Maximum Id in a “global variable” and just change it when a new user is created, in a way to avoid the app to identify Maximum Id, which seams to be the task consuming time, but I didn’t find a way to do so.

Appreciate any idea.

Rafael Roseira

Hi, @rafaelroseira

I’m sort of surprised that it’s that task consuming so much time here.

How long does it take for a user to be created?

you should use the Random component to generate a UUID, it’s much more reliable and efficient

You can create a collection called “Global variables” with only 1 record. Add a number parameter called “User Count” and set the number of users you currently have in that parameter.

On your signup action, you can add a formula to grab this number and add 1 by inserting ID as a “set automatically field” and placing “Global variables > user count > sum” +1

You would then need to have a countdown timer list on the next screen to update the global variable.

Update the global variable to the new user’s ID and link to the home screen.

By storing your global variables in 1 record of a collection, everything is sped up without having to load massive counts.

Hello Bobby. I am not measuring the time to create the user in the database, but the screen where this operation happens kind of freezes because of the operation. It takes around 10 seconds for the screen to get updated.

Thanks for the suggestion Bioveneris. I think this approach is quite strange, since I may have the risk to generate duplicate IDs. To reduce that risk, I can use a large ID mask, let’s say with 10 characters long when today I need just 5 (I have around 12,000 users). Or I can combine the random number with the current time, or something like that. Well… I will think more about it, maybe give it a try, but I do think it is an odd way to create a simple ID. I just need the platform to have a good performance when dealing with the Maximum feature. Thanks.

Thanks for the suggestion Flawless. I tried this initially but faced a restriction to access the “Global Variable” database. Maybe I was doing something wrong, I will try it again.
The countdown piece of the solution is something that got me intrigued. You suggest that so the app has time to properly update the database? A break on user experience to circumvent the platform performance, right?

Hi @rafaelroseira ,

Try this,

This is actually a 1-record collection and can track the last number, in this case customer id number, so the next customer id will be increased by 1.

It will not duplicate.

It doesn’t have to be a break on UX if you make it look smooth with a lottie file.

Thanks for the suggestion Yongki. I will test it and see how it goes.

1 Like

You’re right… the “Please wait” modal screen seems nice. I will give it a try. Thanks!

1 Like

Happy to help :slight_smile:

Hi @rafaelroseira ,
If you don’t need to use a specific ID with prefix or suffix, and you can use the internal ADALO ID number, you can just use this method:

Adding ID to Adalo Collection - Via Adalo API - YouTube

It creates the records in collections via the ADALO API
It updates the user or another collection, you choose which. with the correct Adalo ID

Thanks for the suggestion JL… it is really great to know about the use of Adalo API inside the platform. I didn’t know about that. Thanks!

I implemented the countdown suggestion and now I understood its value. It really solved a restriction I was having: how to access the “Global Variable” to update it. Initially, I thought the countdown was to “give time” to the platform to update the variable properly. But now I understand it is used to substitute the “click” on the list. My app is running smoothly now. I don’t know why, but using the “Maximum” operation among my large database (+12k users) in one screen was creating a delay on additional screen. It seams the operation is so process consuming that the app becomes unstable for a while, even though using it with screens after the screen holding the Maximum operation. I solved the issue with the Global Variable approach. Thanks!

Hi bioveneris. I’m curious: when you say “it’s much more reliable and efficient”, what do you mean?

What is unreliable about MaximumId +1? Is there a risk of duplicating ID numbers?

I use MaxId+1 (but I’m still developing my app) and, from what I’ve read on this forum, it seems to be the only way to create sequential ID numbers. (I have to use sequential numbers for other reasons).

Am I missing a risk that I’m not aware of?

This would have little chance to happen, only for heavy users apps, but definitely could happen with multiple concurrent submissions, since there is no duplicate validation in the creation process.

Max ID is a quick and dirty solution, it works good but also has the flaw I mentioned.

That is why I suggested using this practice: Adding ID to Adalo Collection - Via Adalo API - YouTube

An Adalo ID will never change for the user.

Absolutely, there is a risk of duplicating ID numbers. Maximum ID+1 starts to slow if there are more than 10+ records.
See: Screen Recording 2022-07-21...
I add 22 records to a collection with only 47 records and in the process, you’ll see that the ID numbers are duplicated.

The odds of someone adding 22 records simultaneously like this is slim when you first create the app, but the chance of records being created simultaneously increases significantly when you have 1,000+ users.

Hi @rafaelroseira

I use this formula when the user registers to assign them an ID:

Screenshot 2022-01-14 at 06.44.48

Current time is already a unique value as it changes every second. You could have the case that two or more users click on register at the exact second. That’s why I added the random function between 1 and 1,000. That significantly reduces the probability that two users will have the same ID.

This has been working on my app with no issues.

I hope that helps.


So I guess the actual problem is that, once you grow to a certain size, there is a real possibility that multiple users will create accounts simultaneously and possibly be assigned duplicate numbers. Is that correct?

In my case, I also print physical ID cards with member ID numbers, because I have many older customers who will never use the app. When a member avails of services in my store, they will either show their profile screen on the app or show their physical ID card.

So I’ve printed several hundred physical ID cards, with sequential Member ID numbers, just for them. Sequentially is the only practical way to print them in bulk. I will still create a user profile for those people who don’t use the app, just so I have all my members in one consolidated list.

If I have to use a randomly generated ID a number, I’ll have to print cards one at a time, which will require special ID card printer (very expensive).

Can anybody offer a suggestion for how I can have the app automatically generate ID numbers but still be able to print physical cards with those numbers in bulk?