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.
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
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?
Thanks!
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:
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).
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.
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.
I use this formula when the user registers to assign them an ID:
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.
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?
