issue_comments

One point of complexity: datasette can be used to bundle multiple .db files into a single "app".

I think that's OK. We could require that the datasette_files table is present in the first database file passed on the command-line. Or we could even construct a search path and consult multiple versions of the table spread across multiple files.

That said... any configuration that corresponds to a specific table should live in the same database file as that table.

Ditto for general metadata: if we have license/source information for a specific table or database that information should be able to live in the same .db file as the data.

It could also be useful to allow users to import a python file containing custom functions that can that be loaded into scope and made available to custom templates.

That's now covered by the plugins mechanism - you can create plugins that define custom template functions: http://datasette.readthedocs.io/en/stable/plugins.html#prepare-jinja2-environment-env

The other major limitation of APSW is its treatment of unicode: https://rogerbinns.github.io/apsw/types.html - it tells you that it is your responsibility to ensure that TEXT columns in your SQLite database are correctly encoded.

Since Datasette is designed to work against ANY SQLite database that someone may have already created, I see that as a show-stopping limitation.

Thanks to https://github.com/coleifer/sqlite-vtfunc I now have a working mechanism for virtual tables (I've even built a demo plugin with them - https://github.com/simonw/datasette-sql-scraper ) which was the main thing that interested me about APSW.

I'm going to close this as WONTFIX - I think Python's built-in sqlite3 is good enough, and is now so firmly embedded in the project that making it pluggable would be more trouble than it's worth.

I'll have the error message display a link to the documentation.

The /.json endpoint is more of an implementation detail of the homepage at this point. A better, documented ( http://datasette.readthedocs.io/en/stable/introspection.html#inspect ) endpoint for finding all of the databases and tables is https://parlgov.datasettes.com/-/inspect.json

I'm going to close this as WONTFIX for the moment. Once Plugins #14 grows the ability to add extra URL paths and views someone who needs this could build it as a plugin instead.

I think the way Datasette executes SQL queries in a thread pool introduced in #45 is a good solution for this ticket.

This is an accidental duplicate, work is now taking place in #266

Implemented in 76d11eb768e2f05f593c4d37a25280c0fcdf8fd6

Documented here: http://datasette.readthedocs.io/en/latest/json_api.html#special-json-arguments

Oops, that commit should have referenced #121

This shouldn't be a comma-separated list, it should be an argument you can pass multiple times to better match #255 and #292

Maybe ?_json=foo&_json=bar

I've changed my mind about this.

"Select every record on the 3rd day of the month" doesn't strike me as an actually useful feature.

"Select every record in 2018 / in May 2018 / on 1st May 2018", if you are using the SQLite-preferred datestring format, are already supported using LIKE queries (or the startswith filter):

• https://fivethirtyeight.datasettes.com/fivethirtyeight/inconvenient-sequel%2Fratings?timestamp__startswith=2017
• https://fivethirtyeight.datasettes.com/fivethirtyeight/inconvenient-sequel%2Fratings?timestamp__startswith=2017-08
• https://fivethirtyeight.datasettes.com/fivethirtyeight/inconvenient-sequel%2Fratings?timestamp__startswith=2017-08-29

I implemented this as ?_ttl=0 in #289

Closing this as obsolete in favor of other issues tagged documentation.

I'm handling this as separate documentation sections instead, e.g. http://datasette.readthedocs.io/en/latest/spatialite.html

Closing this as obsolete since we have facets now.