Does what it says and nothing else. This is the same set of paths as Datasette uses.

:books: Documentation preview :books:: https://sqlite-utils--536.org.readthedocs.build/en/536/

This also passes in the extension path when specified in GIS methods. Wherever we know an extension path, we use db.init_spatialite(find_spatialite() or load_extension).

:books: Documentation preview :books:: https://sqlite-utils--531.org.readthedocs.build/en/531/

I end up with these in my local directory:

.hypothesis/
Pipfile
Pipfile.lock
pyproject.toml

Might as well gitignore them.

Closes #418

This adds four files to .gitignore:

.hypothesis/
Pipfile
Pipfile.lock
pyproject.toml

Those are all generated in the course of development and testing.

This is a fairly new feature -- SQLite version 3.31.0 (2020-01-22) -- that I, admittedly, haven't gotten to work yet. But it looks incredibly useful: https://dgl.cx/2020/06/sqlite-json-support

I'm not sure if this is an option on add-column or a separate command like add-generated-column. Either way, it needs an argument to populate it. It could be something like this:

sh sqlite-utils add-column data.db table-name generated --as 'json_extract(data, "$.field")' --virtual

More here: https://www.sqlite.org/gencol.html

Closes #398

This adds SpatiaLite helpers to the CLI.

```sh

init spatialite when creating a database

sqlite-utils create database.db --enable-wal --init-spatialite

add geometry columns

needs a database, table, geometry column name, type, with optional SRID and not-null

this will throw an error if the table doesn't already exist

sqlite-utils add-geometry-column database.db table-name geometry --srid 4326 --not-null

spatial index an existing table/column

this will throw an error it the table and column don't exist

sqlite-utils create-spatial-index database.db table-name geometry ```

Docs and tests are included.

Now that #385 is merged, add CLI versions of those methods.

```sh

init spatialite

sqlite-utils init-spatialite database.db

or maybe/also

sqlite-utils create database.db --enable-wal --spatialite

add geometry columns

needs a database, table, geometry column name, type, with optional SRID and not-null

this needs to create a table if it doesn't already exist

sqlite-utils add-geometry-column database.db table-name geometry --srid 4326 --not-null

spatial index an existing table/column

sqlite-utils create-spatial-index database.db table-name geometry ```

Should be mostly straightforward. The one thing worth highlighting in docs is that geometry columns can only be added to existing tables. Trying to add a geometry column to a table that doesn't exist yet might mean you have a schema like {"rowid": int, "geometry": bytes}. Might be worth nudging people to explicitly create a table first, then add geometry columns.

Refs #79

This PR adds three new Spatialite-related methods to Database and Table:

• Database.init_spatialite loads the Spatialite extension and initializes it
• Table.add_geometry_column adds a geometry column
• Table.create_spatial_index creates a spatial index

Has tests and documentation. Feedback very welcome.

Following our conversation last week, want to note this here before I forget.

I've had a couple situations where I'd like to do a bunch of updates in an async event loop, but I run into SQLite's issues with concurrent writes. This feels like something sqlite-utils could help with.

PeeWee ORM has a SQLite write queue that might be a good model. It's using threads or gevent, but I think that approach would translate well enough to asyncio.

Happy to help with this, too.

I have a project going where it would be useful to do some spatial processing in SQLite (instead of large files) and then output GeoJSON. So my workflow would be something like this:

1. Read Shapefiles, GeoJSON, CSVs into a SQLite database
2. Join, filter, prune as needed
3. Export GeoJSON for just the stuff I need at that moment, while still having a database of things that will be useful later

I'm wondering if this is worth adding to SQLite-utils itself (GeoJSON, at least), or if it's better to make a counterpart to the ecosystem of *-to-sqlite tools, say a suite of sqlite-to-* things. Or would it be crazy to have a plugin system?