issue_comments

Also need to update the datasette.urls methods that construct the URL to a database/table/row - they take the database name but they need to know to look for the route.

Need to add tests that check the links in the HTML and can confirm this is working correctly.

Need to update documentation in a few places - e.g. https://docs.datasette.io/en/stable/internals.html#remove-database-name

This removes a database that has been previously added. name= is the unique name of that database, used in its URL path.

I think I've got this working but I need to write a test for it that covers the rare case when the route is not the same thing as the database name.

I'll do that with a new test.

I'm trying to think if there's any reason not to use route for this. Would I possibly want to use that noun for something else in the future? I like it more than route_path because it has no underscore.

Decision made: I'm going with route.

I'm going to keep path as the path to the file on disk. I'll pick a new name for what is currently path in that undocumented JSON API.

Pretty sure changing it will break some existing plugins though, including likely Datasette Desktop.

The docs do currently describe path as the filesystem path here: https://docs.datasette.io/en/stable/internals.html#database-class

Good thing I'm not at 1.0 yet so I can change that!

I'm inclined to redefine ds.path to ds.file_path to fix this. Or ds.filepath.

The output of /.json DOES use path to mean the URL path, not the path to the file on disk:

{ "fixtures.dot": { "name": "fixtures.dot", "hash": null, "color": "631f11", "path": "/fixtures~2Edot", So that's a problem already: having db.path refer to something different from that JSON is inconsistent.

Right now if a database has a . in its name e.g. fixtures.dot the URL to that database is:

/fixtures~2Edot

But the output on /-/databases doesn't reflect that, it still shows the name with the dot.

Marking this as blocked until #1660 is done.

Implementing this is a little tricky because there's a whole lot of code that expects the database captured by the URL routing to be the name used to look up the database in datasette.databases - or via .get_database().

The DataView.get() method is a good example of the trickyness here. It even has code that dispatches out to plugin hooks that take database as a parameter.

https://github.com/simonw/datasette/blob/61419388c134001118aaf7dfb913562d467d7913/datasette/views/base.py#L383-L555

All the more reason to get rid of that BaseView -> DataView -> TableView hierarchy entirely: - #1660

Options: - route_path - url_path - route

I like route_path, or maybe route.

Worth noting that the name right now is picked automatically to avoid conflicts:

https://github.com/simonw/datasette/blob/61419388c134001118aaf7dfb913562d467d7913/datasette/app.py#L397-L413

The Database class already has a path property but it means something else - it's the path to the .db file on disk:

https://github.com/simonw/datasette/blob/61419388c134001118aaf7dfb913562d467d7913/datasette/database.py#L29-L50

So need a different name for the path-that-is-used-in-the-URL.