I have previously seen issues whereby the subsequent part of a compound action doesn’t have access to a Row ID created by a previous Add Row part of the same action. Presumably this is because the action has executed quicker than Glide can create and add the Row ID.
But if we have the Unique ID special column then why would we ever need the automatic Row ID column type and the potential delay that it introduces.
I guess because (a) we might forget to use Unique ID or (b) rows might be added from elsewhere and not Glide e.g. Integromat or a user adding rows via Google Sheets.
Or maybe the latest update to actions, with the spinner visible whilst the action executes, provides some sequencing so that RowId is updated before the next part of a compound action?
I’d flip this question around and throw it back at you. Why would you ever manually add unique IDs with every single add row action everywhere in your app, when all you need to do is create a RowID column once, and the job is done?
The RowID text in a field from one Table can’t be copied and pasted into a field in another Table as part of a Relation, (PK/FK). I’m realizing this as I’m doing a lot of manual data entry in the back end of my app, one table at a time. Another Unique ID wouldn’t solve this in my case as that gets added through the front end, but I’m just pointing out a possible reason for wanting a manually accessible Unique ID the way that Glide works now.
Why not?
As long as it’s a single relation that should be perfectly doable. (You cannot do Set Columns via multi-relations, but Row ID columns are nothing special in that regard).
I’m talking about from within the Tables though in the back end. Yes, I can make a Relation between Tables and add values to both from within my app interface, but I can’t find a way to do it from the back end with the RowID. I tried making a Template Column that copies over the RowID, but even that isn’t able to be copied as text that I can paste in another Table.
It’s not something that I would do on-going, but during this part of mass data entry it would be nice to have better spreadsheet type capabilities in the Glide Tables. They’re very onerous for data entry, which I didn’t know when I got started. I’m very happy to be proven wrong if there’s something I missed.
Now I have one app with Glide Tables, and one app with Google Sheets, so I can compare the functionality and user-friendliness of the two.
Okay, but that’s a general challenge associated with large scale import and/or export from Glide tables, and really has nothing to do with using Row ID’s vs Unique Identifiers as UUIDs, right?
Well, let’s say I created a Table that isn’t the User Table, (no email), and entered a lot of data through the app interface, giving the entries a Unique ID. Then later I want to add other data in new Tables that relate back to my original one, but from the back end for expediency of the new data entry - the Unique ID would be accessible to me to copy and paste in the new Tables to jumpstart the Relation, whereas the RowID would not.
Maybe this is an edge case, but somehow I experienced it on my first app LOL.
hmm, I guess I must be missing your point.
I don’t understand the difference between copy/pasting one or the other. They are both just columns containing data. Once you add a Row ID column to a table, Glide will auto-generate ID’s for all existing rows.
Yes but the RowID is locked, you can’t copy and paste it. So I can fill out Table1 with lots of data and have RowID’s, but when I want to make Table2 and have them relate I can’t grab the RowID’s from Table1 to add to Table2 as a foreign key, at least through the back end.
I’ll take the time to show it soon. I just need to get my app running better first because I had some complaints today from Users.
Hey @Darren_Murphy. My issue has been the delay in the Glide generation of the RowId. For example, in a compound action, add a row with RowdId in one sheet, then retrieve it immediately, to get the value of the RowId, to use for adding a linked row in another sheet. Make sense?
yep, I get what you mean.
Relying on actions to happen in any particular order in a multi-action sequence always seems to be a bit hit and miss.
Just re-read you original post. So instead of using Row ID, you’ll take the Unique ID column value from one table, and use that when adding a new row to another table, yes?
That’s actually probably a more reliable approach.
Correct, Glide Table issue only. I ended up exporting my data and opening the file in Excel. This allowed me to copy/paste the RowID’s of one Glide Table back to another Table. I will do things differently in the future…
I have a single value that pulls the last row from the sheet in question. Given that this happens immediately after the row is added I can pretty much guarantee that it’s the correct one. Make sense?
I don’t think (?) I’m saying this is a bug, rather I’m just thinking out loud about the best way to handle a common situation and perhaps looking for a recommendation. I goes like this:
Requirement
I have a compound action
It needs to create a row in a “parent” sheet
It then needs to create a related row in a “child” sheet
The relation is achieved by having the child row contain a unique ID referencing the parent row
This needs to be an atomic operation i.e. both rows need to be added and related correctly
Making the Relation Between Parent & Child
I have used a Single Value column to retrieve the last row in the parent sheet immediately after adding the new row to it. This gives me access to the unique ID so that I can use it when I add the row to the child sheet in order to create the relation.
Setting the Unique ID in the Parent Sheet
Approach 1 - Use a RowId Column in Parent Sheet
In this scenario Glide will automatically add a unique ID into the RowId column when I add a new row to the parent sheet. However I have definitely seen (maybe a while back) a slight delay before the RowId column is populated in the new row. This means that my Single Value column has seen an empty RowId and therefore I have not populated the child sheet correctly and the relation has not been made.
Approach 2 - Use a Unique Identifier Special Value
In this scenario I do not configure a RowId column in the parent sheet, rather just a text column which I call Unique ID. I then populate this “manually” using a unique identifier special value when I add a row to the parent sheet. Experience suggests that this value is always immediately available so that the Single Value column can access it and be used to populate the child row correctly thereby forming the relation.
So my question to you is, are either of these methods equally acceptable to achieve the end goal and have there been any recent (month or so) changes to compound actions that would ensure my previous occassional timing issues are no longer likely (e.g. I see that compound actions now show a spinner, maybe indicating some form of serialisation).