I just hit the “New Page from data” option in the Builder - just verifying that any changes made to the tables will be visible in both build environments - aka they stay in sync.
BTW - thanks @Darren_Murphy for your advice to move ‘filters’ into tables that resolve to a ‘true/false’ . I would hate to have to rebuild all these filters in Pages. This should go into the “Hot Tip” log that someone is creating.
Along with “if you are using working tables for custom forms make sure they are Glide tables (instead of sheets) for performance reasons”. I still need to fix this structural mistake.
If you chose “Keep same sheet”, then yes both your original App and your new Pages project will be sharing the same data source.
But if you chose the red pill (Copy the sheet), your Pages project now has it’s own independent copy of the data. Changes made in one will have no effect on the other.
I believe data will stay in sync, but if computed columns are added, removed, or changed, that won’t carry over to the other project, correct? You would have to maintain computed columns in both projects.
Actually yes, that’s correct.
When you first make the copy, you get all your computed columns. But if you add any more, they need to be added in both.
Although interestingly, User Specific values will be shared across both projects. ie. change a user specific value in one project, and you’ll see the same value change in the other project.
This is disappointing since Pages is a portal page for the App and having to ‘add’ computed columns to both sides is a huge pain and not a very good selling point for Glide within a corporation.
I believed/understood that once synced the data/meta-data would stay in-sync and that I could build within either the Portal / App with changes to the data/schema staying in lockstep.
Is their a tool to “diff” the DB changes or do they have to be tracked manually?
I don’t view USC columns as computed columns though. Maybe a sort of hybrid, but they’re really just basic columns stored in a hidden table and accessed through a sort of relation/lookup. It’s still data coming from the database as opposed to something computed on the fly.
The data itself will always be synced. Even if you add new basic columns, they are synced. While I would agree that it would be nice if new computed columns would carry across as well, I can understand cases where you wouldn’t want that to happen. Apps and Pages are very different, and the design and layout of each will be different.
I would hate to have computed columns that I need for apps also showing up in my page project if I don’t need them and do things slightly different in the page. Maybe the page needs it’s own computed columns that wouldn’t be used in apps. Otherwise you eventually end up with columns in one project that are needed for another project, and when you use the ‘Find All Uses’ function, they appear to show up as unused in the current project. In that case you would probably delete that computed column and it would sync to the other project, thereby screwing up the other project.
Keeping computed columns in sync across multiple projects may sound like a good idea initially, but after a few years of maintaining both projects and making incremental changes to each project, you will end up with a lot of fragmentation regarding which computed columns are needed for which project. To keep things clean and organized, I guess it makes sense not to sync computed columns.
If you are adding new functionality (which includes new computed columns) you are going to have to build screens or add components in both projects anyway. Better to know that what you are adding is for that project only, and also, any tweaks to an existing computed column won’t affect another project. That’s my personal view anyway. I’m thinking long term when these projects turn 1, 2, or 3 years old and tables become more complicated. Trying to track each column if it’s used in a project, in another project, or not at all, could become a nightmare. I think it’s great that glide at least duplicates the computed columns initially to give you a jumpstart. From there it makes sense to me to allow differences in computed columns per project.
I look at it like this coming from the code world. Basic columns are the database. Computed columns are the code that runs on top of the database. It’s just code that happens to be shown within the database. Each project has it’s own code layer that refers to the data (the basic column data). Each project will have different variations in it’s code.
I’d say probably yes. Glide tables are independent from each other, unlike a google sheet, for example, which includes all sheet tabs as tables. Whereas a google sheet is all or nothing, a glide table can be added or removed individually and independently from a project.
What I would expect to sync across multiple projects, is a basic column inside of an existing table that is already part of both projects.
I agree with what Jeff said, but I would add that if you need to use this new table in your Pages project, you do have the option of linking it. Basic columns in that table would then remain in sync between the two projects.
Son-of-a-gun. I just went to Data Sources and clicked on my project name and found a bunch of tables. I assume these are all the tables created among all the projects in this project directory?
I would like an option to ‘sync’ tables among projects including computed columns. Then it is a user-specified and not automatic which you make very good points about why this could become an issue over the long term.
For now I am keeping track of computed column changes manually (frankly most of them are labels or templated columns used for ‘filtering’ or lookups/relations to bring in fields) which would be handy to sync - but are manageable since the heavy lifting has been done on the App side already and have been brought over very nicely into the Pages projects.
Computed columns are the singularly most powerful aspect of Glide (the layout builder is nice too) and having this shared, I believe, would be a huge boon to corporate builders who typically have DBAs and others on staff who can create things like labels, filters, lookups to maintain some consistency and simplicity for critical shared data that Glide empowers users to build with.
