Comments Jump from one topic to another; paid app

How is the sheet built that contains the row IDs that you use for comments. Is it built from a formula? Does the data shift around? You mentioned sorting earlier. I would never. I have a sheet in my app that’s dynamically built from formulas, but I would never add row I’d to it because I know things would get mismatched real quick. Is this something similar to what you are doing?

I use the built-in comments from glide.
The sheet (posts) is a simple table and the ID is provided by Glide. (Row ID)

There is a script that reorders that table (posts) and I think that now I see that Row ID provided by Glide is not a Record ID but a depended on the actual row it’s in.

I’m trying to get more info on what the Row ID provided by glide is actually based on.

I’d indeed never knowingly use a dynamically built Record ID.

I realize that, but I’m asking about the sheet that the comments component is linked to.

My guess would be the sort script is throwing everything out of sync and Glide can’t properly track the row, so it reissues new row IDs. That or the script is s somehow not accounting for the row id column and clears it out Why are you using a script to sort the sheet instead of sorting in the app? Also, if you need a certain order in the sheet, would it be better to load a separate sheet using a query with an order by, so the original sheet is left intact.

I am genuinely curious as to the result of this because I have been switching my app to use row id and I could run the rush of the same issue, however any during would be manual and but run by a script.

So it’s the app: comments sheet that is created by glide. Don’t do anything else other than looking op some related data with a vlookup since the app: comments ins’t available within the glide data manager.

Yes this is what I want to know now.

I have a navigation component, previous and next POST. However, the posts can be done in different groups. So I need the records of the group together. So the relation to itself can determine the previous and the next without going into posts of different groups.

The sorting in-app isn’t applied until it gets to the front end.

That would be the worse case,… and indeed possible.

Thanks for weighing in.

So the comments component is linked to the app: comments sheet??? Yes, as a log of comments, but what in asking is, what tab in your app has the comments component on it? That’s the sheet I want to know more about, since that is the sheet that should contain the row id used for the comments topic. I don’t care about the app: comments sheet right now.

Take a look at the memories tab here: https://rwtsk.glideapp.io/

I do something similar with previous and next, but I instead use a helper sheet to eliminate empty rows, figure out my previous and next values, then I use a vlookup to return the values to the main sheet.

The POSTS table has the subject people are commenting on.

The coloured ones are ARRAYFORMULAS()

I will try to implement it, and stop the re-order, based you’re example using a helper sheet that I can manipulate. It just seems like a lot of overhead.

Still interested to know how Row ID is generated and under what conditions it changes by the “system”.

Glide generates Row IDs for rows that are missing them. Once a row has a Row ID, Glide will not change it (and neither should you).

Then I have a found a bug. I have copies of the original record with one ID and later it had a different ID. How is that possible?

Clearly that’s not the case. See screenshot.

So under what conditions is a Row ID reissued?

What you are looking at is a Copy of the Posts table that is filled with the Original value from a record added by Glide. (I used a ZAP to get that copy).
So that’s the history.
Then I look up the current Row ID by title (yes they are unique). There you can see that the current Row ID does not match the Orignal posted Row ID.

How do the rows end up in the Copy table? You add them with a Zap? Do you also write the Row ID in that same Zap?

Yes, indeed. Just copying the entire original record.

Could you try the following, please: open the Copy sheet in Google Sheets, then trigger that Zap, and see what happens. Does it add the new record with a Row ID, and that Row ID then later gets overwritten? Could you make a video, please?

Its actually not a new ID.
The sort, first sorts them including resorting of the id. Then the ID’s jump back to the position they where in according to glide.

But I’ll try to catch it on video.

@Mark

Here is the video. At 3.09 you see that the SORT() moved the Glide Row ID then jumps back.
From that moment on you see that all the comments have moved into a different place.

You are looking at a copy of the setup I had running.

  • A user posts
  • Some people comment
  • More posts come in
  • In the original I need the RANDOM value to actually be the FIXED value from the user profile.
  • For navigation purpose I needed to make sure those with that FIXED value where together, therefore I used the Google Action script onchange to sort by that (now RANDOM value) column.

So something in Glide triggers the Row ID’s to change back without changing the other rows back.

PS and yes I could have omitted the file picker,… there is no added value in that.

Yeah obviously the comment didn’t move, the ID was reassigned to a different row.

@Mark can you tell what’s going on? / What happens?

@David then maybe? I’m really really interested to see why this happens,… because I’m unsure what triggers this,… I don’t want to risk building something depending on Row ID’s that in certain circumstances aren’t fixed to the row.

@Jeff_Hager Would the jumping of ID’s like this concern you?

Yes I’d be concerned, but I also would never sort data on the fly like that. Especially when using row IDs. In databases, you don’t normally continuously sort data around. You may have a logical view of the data to see it in different ways, but it’s inefficient to keep moving it around. I do have a sheet that’s dynamically built using a query with Order By, so in my case I wonder if something similar could occur. I also don’t specifically use Row ID’s on that sheet because I know for a fact that they would get mismatched very quickly. I also really only have one main user that uses that particular feature, so there isn’t much risk for conflict. I also have a couple of other sheets where one user will occasionally do manual entry of data and manually re-sort. As long the Row ID’s don’t change after the re-sort, then I think I would still be fine.

I watched your video yesterday, but it went really fast to track and follow everything that was happening. You were on to the next thing on the right side while I was still watching to see what happened on the left side, so it was hard to follow your steps. I don’t know if that was intentional and the rapid changes are part of the problem you are having, or if you were simply just going fast. When I have time, I would like to view it again on a desktop monitor instead of my phone, however I didn’t notice any row IDs changing. I did see your comment count occasionally increment on the wrong row, but I did not observe any post IDs changing. My only observation, and probably the reason you went so fast is that it only happens when the changes are happening in rapid succession. My only guess is that when you are on a row in the sheet, Glide is only seeing what’s in that row position. When you sort the data in the sheet and it re-syncs back to Glide, then the row that the user is on gets moved and a different post takes over that row position. The comments are probably then written to whatever Row ID took over that row position. All of that continuous resorting is probably throwing Glide off as you are updating data for one row that for a moment doesn’t match that row position in google sheets before it gets a chance to re-sync. I know row IDs have their place, but since you are not required to use them, I’m guessing the position of data is crucial to consistent data integrity. Data is stored in Google as well as glide, and if data doesn’t match, then there is potential for problems.

I would maybe further test with 2 devices. Have one device sitting on the first post row. On the other device add a post that will sort to the top and move all rows down one position. Then on the first device, add a comment to the post you’ve been on the whole time. If you can slowly and methodically reproduce the problem instead of beating on it quickly, then it might be easier to see if it can be fixed.

I will say that one time I was testing someone’s app with them. I believe it was a private chat feature in the app. At one point they deleted or reshuffled the rows and I ended up in a different chat, so I believe it’s possible for something weird to happen if you are mucking around with the data.

If time is absolutely crucial, and you absolutely need the data in a certain order in the sheet, then I would most likely try to find a different solution until you figure it and understand what is happening now. Something like using a helper sheet and vlookup instead of re-sorting the data continuously. Re-sorting might be fine on a daily/week/monthly basis for database maintenance, but continuously like that would make me nervous, no matter the case.