As someone managing and maintaining a complex application (~85 columns a sheet), or as someone who would like to design a solution before populating a spreadsheet, I WOULD LOVE a data definition view as an option in the data editor. Currently, I’m having to document the combined view of the spreadsheet columns and glide columns by had to keep track and document what is being built.
E.g. in CSV
Name, data type, user-specific, relationship or link, spreadsheet or glide, category, purpose
Email, Email, -, -, both, user data, communication & authentication
Rating, number, Yes, sheet: column, glide, Ratings, Showing the user their own rating
The follow on request would be to filter those columns quickly and make edits to the options.
The filtering part is already possible, and makes it relatively easy to find and work with columns - particularly if you use a consistent naming scheme.
Thanks for the response, @Darren_Murphy. I’m aware of the search text filter.
I’m creating a definition spreadsheet so that I can document the configuration and quickly filter on other aspects of the data without relying so heavily on a naming convention. For example, A data definition view would allow you to quickly find which relationships actually link to a specific sheet or find which field has a condition that includes a field. Those are things that would be too much for a naming conversion.
I also realize my request is more suited to someone who is more technical or used to working in other data tools or databases. And, as a product guy, I realize this is a balancing act. This view could overcomplicate things for the standard no-code user. This simple spreadsheet view really helps people grasp the starting point or initial mental model they have. I think this advanced feature could keep people growing with Glide after they learn some of the relational database concepts. Glide may very well not want to offer a more advanced view as this could lead to serving customers that don’t fit the bigger vision for the product. Totally understandable if that is the case.
Here is another case where I just found an error in my naming conversion. File Link is not a Link but Provider Profile Link is.
yep, I get where you are coming from, and I’m with you 100%
But yeah, where something like this would fit in the bigger picture view, and how it would be prioritised… not for me to say
Good to hear. I think the biggest thing for me would be to know if a column is tied into any other columns or used anywhere in the app. Deleting a column is nerve-wracking when you think it’s not used anywhere, but really don’t know for sure. Sometimes, due to app complexity, you just lose track of which columns are still used and which are not.
@david
I am not an IT guy, but felt the need to monitor data-components links and built this.
Finally, it was too heavy to manipulate, and I stopped using it.
But maybe can it be useful.
