I often find myself getting lost in them. Given that I wrote the plugin, that bodes ill for other users.
It also sucks when you have other tables colocated in the DSS database. By default, Datasette uses a lot of real estate for each table on the database page. The DSS tables sort to the top alphabetically, which further impairs the user.
The only table that is absolutely essential to show to users is dss_crawl, as it lets you get started.
dss_fetch_cache, dss_host_rate_limit, dss_ops and dss_zstd_dict are mostly implementation details of little interest to most users.
The crawl queue and history are certainly interesting, but I think it's rare that a user wants to see the whole thing. Typically they're interested in a lens of some sort -- active jobs, jobs for a specific crawl.
dss_job is a little similar - often you care about the jobs of a certain crawl, or the active jobs.
Somewhat radical proposal:
Hide all of them except dss_crawl
Potentially add view(s) for the common scenarios. Views don't take as much real estate on the database table, plus they're at the bottom, so this is a cheap win.
...thinking about it, maybe we don't bother with views to start? Instead, we could make the dss_crawl table page and the dss_crawl row page much better.
The number of
dss_table is too damn high.There are 10 such tables:
I often find myself getting lost in them. Given that I wrote the plugin, that bodes ill for other users.
It also sucks when you have other tables colocated in the DSS database. By default, Datasette uses a lot of real estate for each table on the database page. The DSS tables sort to the top alphabetically, which further impairs the user.
The only table that is absolutely essential to show to users is
dss_crawl, as it lets you get started.dss_fetch_cache,dss_host_rate_limit,dss_opsanddss_zstd_dictare mostly implementation details of little interest to most users.The crawl queue and history are certainly interesting, but I think it's rare that a user wants to see the whole thing. Typically they're interested in a lens of some sort -- active jobs, jobs for a specific crawl.
dss_jobis a little similar - often you care about the jobs of a certain crawl, or the active jobs.Somewhat radical proposal:
dss_crawl...thinking about it, maybe we don't bother with views to start? Instead, we could make the dss_crawl table page and the dss_crawl row page much better.