If you, like me, need to have a deep analysis of how a document is built, I’m sure you will appreciate the Doc Inspector.
It’s a tool that allows to get most of the relevant structural information of any any doc (you need to have at least read access), without opening the doc itself.
The Doc inspector comes with:
a visual tables relationship structure (both as a PNG or with the ability to play with an embedded dbdiagram.io, similarly as in @Scott_Collier-Weir’s provided pack) with the possibility to include/exclude tables based on your own criteria.
a visual pages structure along with their contents (tables, views, formulas and controls), fully customizable (choosing what components to show and excluding attributes, subpages, etc)
a fully browsable structure - and partially content - of any document (rows are excluded, for the moment), via connected sync tables. Meaning that you’ll have a detailed view for each block (page, table, view, column, formula, control), with the ability to browse the hierarchy of components without opening the source doc. Or opening the source doc exactly where that component resides.
The homonym Doc Inspector: with all the API retrieval logic
Kroki: a connector for different diagram libraries (such as dbdiagram, plantUML, mermaid, etc)
More info - and a few explaining videos - are directly provided within the doc.
Disclaimer:
Please, keep in mind that - while used in my professional context - this is a personal project and not part of any official Coda release. Therefore, while I’ll keep on fixing/evolving it, it doesn’t have any cadenced maintenance and could be discontinued at anytime.
Oh my goodness, @Federico.Stefanato, it’s like you peaked inside my brain and found what I wished for most for visualizing my coda builds! I am so excited for this, thank you so much for sharing!
This seems great. I rarely see the utility of coda ai, but I wonder if this would be an opportunity for coda ai to suggest ways to restructure a doc to make it more efficient or clean it up.
Is it possible to hide columns from the generated table schema? If not, could you add that as a feature request?
I have a large document I’m working with (60-70 tables), and I want to focus on the connections between them (lookup columns only) to reduce the noise.
Hey @AJM ,
this is a great suggestion! I am actually working on something like this, but I don’t have any realistic ETA.
As you can imagine, there are several different opinions on how to best structure a document, but some best practices are always valid.
I’ll add some considerations to the document itself as soon as I have something publishable.
Please, keep in mind that in order to keep some formal consistency, there are some… workarounds.
e.g. there are no primary keys on Coda tables (or better, there are internal RowID, but it might lead to confusion), so I simply assumed that display columns act as primary keys, which is kind of forced, but intuitive.
I also changed the syntax generation strategy for both tables and pages.
Now you should not receive any Coda error when dealing with huge schemas.
Hi @Federico.Stefanato, this is exactly what I need but after strictly following the instructions I get the following error. Don’t want to make the doc public because it would expose too much data, but would you mind if I share it with you?
Digging into this problem with @Pablo_Duart, I realized there was a small issue with a slider control.
It’s now fixed (v.1.3.1) and I suggest to always take a look at the latest published document.
In case anyone of you is also experiencing a rounding error when generating diagrams, please, be sure you have the slider_CellMaxLength control (Admin/Variables page) set to 43.000. Or, in any case, a value higher than 0.
