Shared table does not keep show Row ID

[David_Gabler]

Hi, I copied an app to make a new app, and one of the tables has evolved quite a bit – mostly from adding new rows. Since I don’t want to maintain the table in both apps, I added the evolved table to the older app, thinking I would modify the screens to use the shared table, and eventually remove the older table with fewer rows.

When I added the newer, maintained table, however, the Row ID did not come over. Nor did any of the computed columns. These are both Glide tables. Since each app may need different computed columns, that’s OK, but how can I maintain a relation w/o the Row ID?

I see that user-specific columns seem to work between the two apps (the settings are maintained). I have not tested “row owners” yet. This particular table simulates row owners using filters.

What is considered best practice when sharing a complex table between apps (where the Row ID matters)? This is not simply a lookup table.

Old table:

New table “linked” to older app:

UPDATE: Making @Owner a “row owner” seems to work. But I had to do it independently in both apps. The setting seems to be independent of the app. Also, renaming the table in one app (the first app to own the table) shows in the list of available tables as renamed, but in the other app, it still has the old name.

Just not sure what I am supposed to be seeing, or how Glide is handling things. I know it would be easy to share a simple lookup table, but this table is more complex, and not sure how changes I make in one app will affect the other app that uses the same table.

And the more I think about it, the more I’m certain that the Row ID is important even in a lookup table, in order to standardize the database. Think about a misspelled word. Easy enough, modify the lookup table and it automatically corrects the spelling everywhere – because it’s tied to a Row ID

[Jeff_Hager]

It’s expected that computed columns will not carry over when reusing an existing table with another app.

I explain what I think is happening with RowID’s here. Because the same RowID is maintained behind the scenes, that’s why user specific columns work between both apps.

Glide App and Page with same Row ID

Glide tables technically have a RowID already built in. Adding a RowID column just exposes and makes visible the RowID that was already assigned to the row. That is of course different from Google sheets, where RowID’s are not generated until you add the RowID column. So in your case, it’s possible that glide didn’t deem it necessary to show the RowID column since it was already there behind the scenes. That’s probably why you got the same ID’s once you added the column to the table. I woul…

Not sure about Row Owners. It probably loses the designation but resetting the column as a row owner column should work just fine, unless maybe you are using anonymous emails and you get assigned a different anonymous email in the second app. I’m not sure though.

As for renaming, I’m sure the table name is just a cosmetic thing on the surface. In reality there is probably an underlying ID that is the same in both apps, so it remains as the same table between apps, but the name you see is more than likely tied to the app itself. If a data change from one app is reflected in the other app, then I don’t think you should have a problem.

[David_Gabler]

@Jeff_Hager

Because the same RowID is maintained behind the scenes, that’s why user-specific columns work between both apps.

Except that if I add a component to the secondary app (the one that “inherited” the table, the Row ID is not available to be selected in the dropdown component.

But when I add Row ID to the “inherited” table, they seem to be the same Row ID’s. So I will let you know what else I find in this test. BTW, both apps are PRO, but I made a copy to work and test with of each app, so they have real emails, but they are “free” for testing.

[David_Gabler]

@Jeff_Hager

unless maybe you are using anonymous emails and you get assigned a different anonymous email in the second app. I’m not sure though.

Oh, missed this. Yes, I have so many free apps and a handful of beta testers, so I think I can confidently say that Glide assigns the same anon. email to the same email address every time. It’s just that we cannot see the true email. And when you go live (pro), at least at this point, you need to delete user data for all your anon. emails or Glide assigns the anon. email when they log into the pro app. That was very frustrating to me.

[David_Gabler]

@Jeff_Hager

It’s expected that computed columns will not carry over when reusing an existing table with another app.

What about user-specific columns? The program that inherited the table does not have those columns, but many of the users in app2 are also in app1. Shouldn’t those values carry over to the second app?

[Jeff_Hager]

I think of User Specific columns the same way that I think of any other computed column (although they work a little differently). Basically any column that you would never see in a google sheet, I would consider a computed column.

Most computed columns are computed on the user device. Obviously that isn’t quite the case with user specific columns…except when a user is not signed into the app. When a user is not signed into the app, then user specific column values are stored locally, and only until the app is closed (at which time, they are wiped out). If a user IS signed into the app, then the value is stored on glide servers, but not in tables. I think what Glide does is create an invisible table to store the RowID, the user’s email, and the value for that user specific column. Then they essentially create an invisible relation/lookup to retrieve that value into the user specific column in the main table. Thus, I think a user specific column is more like a lookup column. This becomes more apparent of you export your data, which let’s you see those hidden tables for user specific data.

Now I’m not sure how this works with a table that’s shared across apps. You could recreate the missing user specific columns, but I don’t know if they would have different underlying column IDs and you wouldn’t be able to regain access to the existing user specific values in the shared table. The only surefire way to carry all computed columns over to a second app is to duplicate an app with the same tables. I assume that would retain connections to existing user specific values across both apps, but it seems like that may not be a solution for your use case.

I really don’t know how glide handles everything behind the scenes. It’s something I would have to do some extensive testing to fully understand what can and can’t be done. I’ve never had to share tables between apps before, so I’m not very experienced in that department.

[David_Gabler]

@Jeff_Hager

The only surefire way to carry all computed columns over to a second app is to duplicate an app with the same tables.

Thanks for sharing your experience. In my case, I want to have a central set of tables that will be common to all the child apps. The primary app will be the one used to maintain those tables, and will have the same users. But the child app will have its own set of other tables (that also exist in the main app). So I wouldn’t be able to just copy the app, unless it were possible to only copy certain tables, and leave the rest shared. Right now that’s not possible with Glide.

I’ll continue to brainstorm this and see if I come up with something viable. If not, copying and implementing a new app will become quite a chore.