I believe this also provides a workaround for the problem I face in https://github.com/simonw/datasette/issues/1300.

Now I should be able to get table PKs and generate a row URL. I'll test this out and report my findings.

```py from datasette.utils import path_from_row_pks

pks = await db.primary_keys(table) url = self.ds.urls.row_blob( database, table, path_from_row_pks(row, pks, not pks), column, ) ```

There's a workaround: https://css-tricks.com/css-fix-for-100vh-in-mobile-webkit/

and a future fix: https://css-tricks.com/safari-15-new-ui-theme-colors-and-a-css-tricks-cameo/

I ended up using some JS as a workaround.

First, add a JS file in metadata.yaml:

yaml extra_js_urls: - '/static/app.js' then inside the script, find the blob download links and replace .blob extension in the url with .jpg and replace the links with <img/> elements. You need to add an output formatter to serve BLOB columns as JPG. You can find the code in the first post. ~~Replacing .blob -> .jpg might not even be necessary, because browsers only care about the mime type, so you only need to serve the binary content with the right content-type header.~~. You need to replace the extension, otherwise the output renderer will not run.

```js window.addEventListener('DOMContentLoaded', () => { function renderBlobImages() { document.querySelectorAll('a[href*=".blob"]').forEach(el => { const img = document.createElement('img'); img.className = 'blob-image'; img.loading = 'lazy'; img.src = el.href.replace('.blob', '.jpg'); el.parentElement.replaceChild(img, el); }); }

renderBlobImages();

}); ```

while this does the job, I'd prefer handling this in Python where it belongs.

If there's a simpler way to generate a URL for a specific row, I'm all ears

If I change the hookspec and add a row parameter, it works

https://github.com/simonw/datasette/blob/7a2ed9f8a119e220b66d67c7b9e07cbab47b1196/datasette/hookspecs.py#L58

def render_cell(value, column, row, table, database, datasette):

But to generate a URL, I need the primary keys, but I can't call pks = await db.primary_keys(table) inside a sync function. I can't call datasette.utils.detect_primary_keys either, because the db connection is not publicly exposed (AFAICT).

I'm seeing the problem on database page. Index page and table page runs quite fast.

• Tables have <10 columns (id, url, title, body_html, date, author, meta (for keeping unstructured json)). I've added index on date columns (using sqlite-utils) in addition to the index present on id columns.
• All tables have FTS enabled on text and varchar columns (title, body_html etc) to speed up searching.
• There are couple of tables related with foreign keys (think a thread in a forum and posts in that thread, related with thread_id)

EDIT: I misunderstood the problem. This seems like a fix better suited for Safari. But I don't have any Apple device to test it.

css body { min-height: 100vh; min-height: -webkit-fill-available; } html { height: -webkit-fill-available; } https://css-tricks.com/css-fix-for-100vh-in-mobile-webkit/

It's actually not that difficult to fix. Well, this is actually a workaround to keep viewport in place.

I usually put a transition (forgot to do it here) that keeps page from resizing.

css .container { min-height: 100vh; transition: height 10000s steps(0); }

steps() function prevents excessive layout calculations, and lets the page snap back into place (10000s ~= 3h later) in a single step. This fix also prevents page from jumping around when the keyboard pops up and down.

Somewhat related: https://github.com/simonw/datasette/issues/859 I fixed the issue with forking and disabling the counts for hidden tables.

Well tests need to be updated.

I need to get tests working on Windows.

Turns out we should include hidden tables in the result dict, or we're breaking tests. I've committed a refactor https://github.com/simonw/datasette/pull/883/commits/4f06e1bf6fbe4b73be770b87f610bf7c0e6e3ea7

I am calling the API from another origin, so injecting CSRF token into templates wouldn't work.

EDIT:

I'll try the new version, it sounds promising

Bearer tokens sound interesting. Where do tokens come from? An auth provider of my choosing? How do they get verified?

Does this mean custom routes get to expose endpoints accepting POST requests? I've tried earlier to add some POST endpoints, but requests were being rejected by Datasette due to CSRF

I've just realized Datasette tries to count hidden tables too. There are 5 visible tables, 25 hidden tables, which I haven't realize earlier to consider their effect. I've turned off counting for hidden tables to see if it has any effect.

What's the point of counting FTS tables?

I tried setting cache_size_kb=0 then cache_size_kb=100000, still getting this behavior. I even changed Database::table_counts and lowered time limit to 1

py table_count = ( await self.execute( "select count(*) from [{}]".format(table), custom_time_limit=1, ) ).rows[0][0] counts[table] = table_count

I feel like 10 seconds is a magic number, like a processing timeout and datasette gives up and returns the page. Index page loads instantly, table page, query page, as well. But when I return to database page after some time, it loads in 10s.

EDIT:

It's always like 10 + 0.3s, like 10s wait and timeout then 300ms to render the page

The issue seems to appear sporadically, like when I return to database page after a while, during which some records have been added to the database.

I've just visited database, page first visit took ~10s, consecutive visits took 0.3s.

Hmm, not seeing the problem now.
I've removed the commented out sections in database.py and restarted the process. Database page now loads in <250ms.

I have couple of workers that check some pages regularly and scrape new content and save to the DB. Could it be that datasette tries to recount tables every time database size changes? Normally it keeps a count cache, but as DB gets updated so often (new content every 5 min or so) it's practically recounting every time I go to the database page?

EDIT: It turns out it doesn't hold cache with mutable databases.

I'll update the issue with more findings and a better way to reproduce the problem if I encounter it again.

sqlite-generate many-cols.db --tables 2 --rows 200000 --columns 50

Looks like that will take 35 minutes to run (it's not a particularly fast tool).

Try chunking write operations into batches every 1000 records or so.

You said "200k+, 50+ rows in a couple of tables" - does that mean 50+ columns? I'll try with larger numbers of columns and see what difference that makes.

Ah that was a typo, I meant 50k.

I think I should mention that having FTS on all tables mean I have 5 visible, 25 hidden (FTS) tables displayed on database page.

I'm not sure if table counts are to blame. There shouldn't be a ~3 orders of magnitude difference.

```fish user@klein /a/w/scrapyard (master)> set sql "select count() from table_1; select count() from table_2; select count(*) from table_3;" user@klein /a/w/scrapyard (master)> time sqlite3 scrapyard.db "$sql" 187489 46492 2229

Executed in 25.57 millis fish external usr time 3.55 millis 0.00 micros 3.55 millis sys time 22.42 millis 1123.00 micros 21.30 millis ```

but not letting datasette count the tables definitely helps.

Oops, the same method is called from both index and database pages. But removing select count queries speed up the page load quite a bit.

Welp, I'm an idiot.

Turns out I had a sneaky comma , after sql key: ... (:name, :url), which tells sqlite to expect another values(...) list.

Correcting the SQL solved the issue.

@simonw yes it works fine on Windows, but test suite doesn't run properly, for that I had to use WSL

I wanted to add a test for it too, but I've realized it's impossible to test a server process as we cannot get its exit code.

```python

tests/test_cli.py

def test_static_mounts_on_windows(): if sys.platform != "win32": return runner = CliRunner() result = runner.invoke( cli, ["serve", "--static", r"s:C:\"] ) assert result.exit_code == 0 ```

I've also added another fix for using static mounts with absolute paths on Windows.