The idea is to manually create a text column alongside the Row ID column that will house a unique human-readable row ID. Once set and used, the text in this column is to never be changed, as if it were not mutable (though technically it is).
When would human-readable row IDs NOT be used
For relations. For relations, it’s always preferable to use the Row ID column, which is both basic and non-mutable.
When could human-readable row IDs be used
To set conditions for visibility conditions, filters and actions in the layout and workflow editors. The associated Row ID could be used instead (and it would make the setup more robust), but using a Row ID can make the initial setup cumbersome because the developer might have to switch back and forth to the data editor, and it can make troubleshooting more complicated. Using the human-readable row ID, especially if it is easy to remember, can make it easier to set up the conditions.
Maybe Mark (@V88) can share more about his approach to human-readable row IDs.
Add an incrementing row number each time a new row is added. Writing the value as the current max row plus one is not only human-readable, but also makes it much easier to locate that row during troubleshooting. In many cases, you don’t even need a row ID anymore, which saves a column full of unnecessary characters. For even better traceability, you might prefix the number with the table name.
This method is fine but I personally prefer using the method using Find element index. It explicitly goes through the steps of what’s happening under the hood.
In the first case with Increment, a row is added, then an increment action is triggered, and finally the row index is set. The increment action being separate from the table is particularly inelegant.
In the second case with Find element index, a row is added and the row index is set. In the same breath. The second method is shorter and really, when a row is added its index is known that very moment, any additional external resource or action is unnecessary. I don’t know what the term in the industry for this is, but I would call it “technical bloat”. The increment action happens outside of the database (data editor) and inside the workflows editor, it make things that much more “unclean”.
You can’t use the findIndex method for creating row IDs — every time you delete a row, all IDs will change. Use a logic column to generate the next row ID value and write the “Simple Row ID” column of the newly added row.
The only issue with this method is that it is subject to concurrency issues, which means it is possible to end up with duplicate row numbers. If uniqueness is critical, then you have two options:
native RowID column
delegate assignment of Row identifiers to an external 3rd party
Do you think Glide doesn’t have a mechanism to prevent that? It should queue row additions; otherwise, they’ll run into problems with many other actions as well.
I know it doesn’t. Glide actions such as Add Row and Increment are not atomic, and never have been. At least not with user initiated actions. Server-side workflows are relatively new, but from what I’ve seen so far I believe that they could be subject to the same concurrency issues.
Same same. Unless ownership of your “pre-calculated value” is delegated to a 3rd party, it’s possible to arrive with duplicates.
Imagine two users adding a row at exactly the same time. Where does each user get that pre-calculated value from? And how do you ensure that they aren’t both using the same pre-calculated value?
Except is isn’t. Because each add row happens on each users local device, and is then synced with the Glide back end.
This discussion has been had several times over the years in this community, and the behaviour is well understood.
The method you have suggested can work to a certain point. If there are a relatively small number of users, then the risk of duplicates is small. But it exists.
Oh, it’s not even sending the row addition request to the server? You must be kidding me. In that case, I give up—LOL. Anyway, who would seriously use Glide for a high-traffic app?
@nathanaelb I don’t really understand why you want to use human-readable row ids instead of using other parameter. Could you elaborate a bit on the need😎
I think we’ve gotten used to the Row ID and Relation columns, but I wonder if Glide could do without. The concepts and use cases would stay of course, but the columns, or at least how they are represented in a table, would go.
With this discussion, I realize that I use Row IDs for relations only, due to their uniqueness. The Row ID column would be there under the hood but unbeknownst to the developer.
The Relation column is like not other in that it doesn’t house any data, it’s simply an indicator column. The column is very practical, but it’s not as natural as the others.
So maybe something could be done with those two columns to simplify the building experience
When it comes to relating data, I don’t think anything is simpler or clearer than a unique row ID. The row ID could be a simple incremented row number, like in MySQL, if Glide supported generating it that way. But then you face the challenge of identifying the table and app—assuming all your data is in one file. They do offer an alternative, like a lookup column. Or if you want to go full PRO, don’t use rows at all—store all your data in JSON and work with it using the JavaScript column.
I’m not convinced this would have anything to do with going “full pro”. It seems difficult to work with JSON strings and JavaScript code rather than tables of data. And Glide is a nocode platform, and in this context working with tables in the data editor seems a more natural experience than JSON and JavaScript.
