This message was deleted.
# secoda-feature-requests
w
This message was deleted.
m
I've only got ~5% of our docs moved over to Secoda so still getting used to things, but my priorities would be: • When clicking on an object in the catalog, the navbar, and most other places, open that object in a new tab by default rather than the current tab. I'd make this an optional setting for users, some I'm sure will want the opposite, but personally I usually have 5+ tables open when I'm working on anything data relatedStore navbar state locally, so that as a user when I open a table in a new tab or reload the page the navbar is open as I had it • Similarly, store state of ag-grid (sorts, filters, column widths, etc) locally, and store each object's preferences separately. Meaning that when I'm viewing a
users
table I may expand the Description column so that it's very wide, but when I'm viewing a
purchases
table I may expand the Profiler/Distributions column so that it's wide. When I come back to view these tables in future it would make my user experience 2x better if those column widths were the same as they were last time I changed them. Same situation if I've applied filters, sorted, etc. • My #1 request, something I haven't seen anywhere else ("column lineage" gets somewhat close sometimes) and I that I think would have a huge positive impact. Let's say I've got a data mart in our warehouse named
users
which pulls in data from a dozen different sources; it has aggregations and whatnot built in dbt, data joined from our production db orders table and Intercom, etc. Where do I document all of these columns? ◦ Take an example of a column
account_created
that orginates from our production postgres db
users
table...obviously, a logical place to document this column would be there: Catalog -> Postgres -> db -> main -> users. So I head there, write a nice long description of what exactly the
account_created
field is, great. What's the problem? The problem is that our BI developer builds his visualizations from our BigQuery marts, not our prod db. So they look at Catalog -> BigQuery -> prod -> users and see no description of what this
account_created
field is. ◦ A good long-term solution to this is column lineage. If we happen to use an ETL tool that Secoda integrates with, and do our warehouse transformations using a tool like dbt that Secoda integrates with, eventually you'll be able to show column lineage. But that's a long term, difficult problem to solve. ◦ A quicker, easier, and better solution in some use cases would be to allow me to do the following: 1. Write the column description once where it should live: Catalog -> Postgres -> db -> main -> users 2. Then allow me to @ tag that description anywhere throughout Secoda. In this example @ tag it in Catalog -> BigQuery -> prod -> users, in the Description column for
account_created
3. Now when our BI dev is looking at the BigQuery
users
table documentation, in the
account_created
Description column they'll see @Postgres - db - main - users - account_created. Ideally hovering over this would show the description, and clicking would open a new browser tab to the prod db users table ◦ Even once column lineage is built, this @ tagging ability would be highly used. I will @ tag the description of some column, a dictionary term, and a collection, all inside the description of some column of some data mart, so that end users of that mart can easily find all the info they need about it
e
Hey @modern-account-72538 thanks for providing the detailed feedback. The first point is a very good one, maintaining the settings for the grid will make a much better UX. I’ve added this item to our backlog and should be completed in the next couple of sprints. On the second piece of feedback, if I’m understanding correctly the root issue you’re experiencing is that you have a description that you’d like to have shared across similar tables/columns right? If that’s the case there are a couple of options currently in the product that makes this easier, but I just wanted to confirm first if I’m understanding correctly.
m
the root issue you’re experiencing is that you have a description that you’d like to have shared across similar tables/columns right?
@elegant-house-93198 yes, that's most of the use case
@elegant-house-93198 any suggestions on how best to do this? Just this morning for example I'm working in our warehouse and we have a calculated value
age_group
for users, sprinkled throughout various tables/marts. If I'm looking at the main
users
table documentation I get to see the description of this field, but if I'm looking at any other table documentation e.g.
users_purchaseanalytics
then of course it's not available
e
Hey @modern-account-72538 what I’d recommend is one of two things: 1. The “magic wand” feature which will copy your column description to all columns with the same name 2. Filter by a specific table name in the catalog, and then copy the description by dragging down on the description cell. It looks like we modified the filters on the catalog to be “Contains” instead of an exact match, so we’ll have to re-add that filter option in. A workaround is you can sort the tables, and it will group all the tables with the same name. If you have any questions about either option please let me know!
👍 1
🙌 1
m
Cool, that'll work. I'm sure your backlog is huge but I think a really valuable feature (especially for large datasets) would be the concept of a "master" that would cascade down automatically
e
This is something that @abundant-crowd-2724 is also thinking about, so I agree that it would be quite useful @modern-account-72538. We’ll try to scope out something that’s ideal based on the feedback and I’ll pass it by you for feedback when it’s ready.