How to increment a number counter field?

Hi
I’ve asked around on another topic on this issue. Does anyone have an idea if this, or any other similar action, is protected from concurrency/race condition?
In other words, what happens if two users trigger the increment action on the same time?
Thanks

No, it doesn’t.
I’ll respond to your other post shortly (I’m away from my computer at the moment).

Hi @Robert_Petitto and @Darren_Murphy,
One of the reasons for using this numeric value was to in order to have a truly 1:1 relationship between tables. This should survive any changes done by the users, including changes I didn’t think about and they somehow find a way to do :slight_smile:
I had an idea which I’d like to run by you:
Assuming we are using a temp working table, how about we take the RowID of that temp line and set it on the relevant table which we’d like to create this 1:1 link?
In order for Glide to regenerate a RowID for each new submission, the submit action will delete that temp row and then add a new row to the same temp table. We delete because just clearing the values won’t regenerate the RowID, it’ll use the same RowID for each user. We have to add a row because without it the user cannot enter the custom form.


Yes Darren, I’m playing around with a copy of your wonderful Custom Forms app :slight_smile: (there’s no real logic with have the 1:1 connection between Animals and Users. It’s just for testing).

Some other questions:

  1. What is the purpose of “unique identifier” and how is it different from RowID? It’s generating a different unique value for each table in which we set values, so it cannot be used as this 1:1 link.
  2. How does the reset button come into play here?

Thanks

Nice question :slight_smile:

I think…

This is the answer you are looking for here. I’ll use my custom forms app as an example. Let’s say we wanted to allow users to add an arbitrary number of images for each animal. How would we handle that? A naive approach would be to add a bunch of extra image columns to the Animals table. But that’s not going to scale - what happens if somebody decides to add 500 pics of their pet cat? Do we have 500 image columns to cater for that possibility? Of course not. We move the Animal pics to a separate table. But we need to be able to link each image to the correct animal, and this is where the Unique Identifier comes in handy. If I was to add that functionality to the demo app, this is how I would approach it:

  • I’d start by creating a new table to hold the images, with columns for the Image and an AnimalID
  • I’d add an extra AnimalID column to the Animals table
  • I’d add another User Specific text column (usc/animal_id) to the Working table
  • When a user opens the form to create a new animal, the associated action would do a Set Column Values on that column, using the Unique Identifier special value
  • Creating a new animal would become a multi-step process. In the first step, they’d just provide the animal name and save. This would add a new row to the animals table, setting the AnimalID to the value of that user specific column.
  • I’d keep the user on the same “form” screen, and then give them an option to add images. One at a time, as many as they like. Each time they save an image, a new row would be added to the Animal Images table, using the same AnimalID value.

This is a bit clunky, and I wouldn’t recommend this. And I’m not even sure how well it would work. I think you’d be much better off leveraging the Unique Identifier.

Which reset button?

1 Like

This reset button :slight_smile:

This is the main challenge with using this unique identifier. A multi=step process means more chances of increasing the abandonment rate in mid process. My goal is always to ask as little as possible from the users, by trying to do as much of the work as possible behind the scenes and with zero involvement from the user. As you can see in the screen shot I sent earlier, the idea is to write to both table with one action. In your example, that would be to write to both the animals table and the image table, all in one swift move. For this, we need the link. Enter RowID :slight_smile: As it’s coming from the worktable, we can use it as a connection between two (or more) table to which we write during the same action. It’s too bad we cannot setup the unique identifier as either a column in the working table (with an option to reset after each submission), or simply configure it to repeat itself with an identical identifier for multiple tables.

Where do you see the problem here? Is it the delete row followed by the add row? Do you know of another method to regenerate the RowID in the working table?

Thanks

oh, right. Not sure how that applies at all in this context.

You could still do that using the Unique Identifier method. The example I gave was to cater for the case where you don’t know in advance how many “child” records the user will be adding once the parent has been created. If in your case it’s just one of each, you can just as easily collect all data and add rows to both tables using a single step.

Yes, but also the fact that’s it’s a really round about way to approach the problem. This is exactly the type of use case the Unique Identifier is suited to, so why not use it? It’s a bit like you have a star screw that you want removed, and I hand you a star screwdriver, and you say “No, thanks - I want to use this flat head screwdriver. Can you tell me how to make it work with a star screw?”

Sorry, I missed this part of your earlier reply.

But you can do that, and it’s exactly what I’m suggesting. You add a user specific column to your working table, and set that with a new unique identifier value when a user opens the form screen. Then when the user submits, you use that value in your Add Row action/s. Because it’s user specific, it will be a different value for each user, and for each new instance of the form.

And this, by the way, is where your RowID idea will fall down. Because the RowID is not user specific, it will be the same value for every user. And so if you have two or more users in the form at the same time… I’m sure you can connect the dots :slight_smile:
And what will happen if the row is deleted by one user, while 3 other users are in the form at the same time? oops…

1 Like

This :point_up_2:

1 Like

Ahhh…I didn’t know that…
Naturally, changes everything and, as you said, kills my idea :stuck_out_tongue:

My bad, I understood earlier that we pass this UniID only upon submit. Not very smart of me…

Forgive me for asking every detail, but I’m still learning the ropes here.
When we open a new screen we set the data to the relevant working table.
However, when coming to set UniID value for “this item” , it shows the columns from the table we came from.
In your example, it’s “Animals”.

I see you added a relation column. Is that specifically for solving this “jump” between tables?
image

image

Yep!

And does it matter what the relation fields should be?
In other words, do we even care if such a relation is indeed found, or if it can even be found?
Even more words, can we link between name and phone number, for example? a never-happening relation

Yes, it matters. If the relation is empty, it can’t be used for this purpose. You’ll notice that I used the ID of the currently signed in user. This is a common technique for building single relations for this purpose. It’s a sound approach, as it’s guaranteed to always work. By work, I mean the relation will always be formed.

Well. I just tried it and it seems it can be used, even if the relation is empty. I think the only requirement is to relate same type of fields, regardless if they’ll ever find a match.
It’s working as far as I can see here. Please forgive me for messing up your wonderful app.

You don’t show how your relation is configured, but my guess is that whatever columns you are joining are both empty. So you do have a match, but because it’s matching two empty values it looks like it’s empty.

Sorry, I thought I did catch the configuration on the video. As you can see above, Name column isn’t Empty, although UniID is empty while not during a active form submission.

Could I get a copy of your test app?

As far as I’m aware, that should not work. And I can’t replicate it, so I’d like to take a look at what you have and see if I can figure out what’s going on.

Sure, here it is. Repeating my apologize for the messy layout in general and for messing with your very tidy app specifically.

hehe, yes my suspicion was correct.

It “works” for you because you have a handful of rows in your Animals table with an empty name. So those rows form a match with the empty UniID column in your working Table. Remove those rows (or give them a name value) and you’ll find that it stops working.

The fact that you have 2 rows in your Working table could potentially throw an extra spanner in the works. The thing to understand with a Single Relation is that it will use the first row that forms a match, which might not always be the first row in the table. This is why using a template with the current users ID is a reliable way to do it in this case, as we can be sure it will always match, and always match the first row.

PS. Please stop apologising :stuck_out_tongue: One of the great things about this community is the sharing aspect… the fact that we have a bunch of people that share their ideas, and others that take those ideas and extend them. So do whatever you like with my app, and if you find ways to improve it then please share :slight_smile:

1 Like

Right on the money. Thanks for clarifying.