Row Numbers

Still thinking about this, but the whole problem is the disconnected nature of glide apps with their own local copy of the database, rather than everything only referencing the central database. I agree we need something to number rows and I highlighted my thoughts in this feature request post:

My best thought (which may not exactly cover limited minting of collectables and allow some to slip through but maybe that can be accounted for) is to create another table to function as a work table. When I say work table, I mean a table with a preset number of rows and a rows that are numbered. If you’ve seen my calendar app, it will make more sense. That calendar is a table with around 30 to 40 rows that are numbered sequentially, but with some math or single value columns, can ultimately represent any possible month of any possible year. That way, an unlimited number of year/month combinations can be represented by those 30-40 rows. So a work table is a table with static rows that dynamically changes, either per user if you use user specific data, or globally with basic column data.

One thing you could consider, is to create another table that’s similar to the CollectibleClaims table, but whenever you create a new collectible, you manually add the number of rows with the collectible ID and a sequential number. Then you create a relation using the collectible ID to the CollectibleClaims table. Finally, you create a series of single value columns to get a user’s claim using the row number to get the row however many positions from the start of that relation. Something like this, but instead of a hard number, you set the Row setting to the row number column.
image

This would pull all those claims into the new table with a set row number. Any additional claim attempts would just be ignored and wouldn’t pull into that new table. The only problem is timing. For a moment, if 2 people claimed a collectible at the same time, they may see that they both received edition #1 and until the data sync back to glide and back to the user again, then one of them will jump to edition #2. In that case, it may help to introduce some sort of timed delay before they see which edition # they get.

Still may not be a perfect solution and will essentially double your row count, but hopefully it may be something you can work with.

1 Like