Aha! This may be possible already: https://github.com/simonw/sqlite-utils/blob/396f80fcc60da8dd844577114f7920830a2e5403/sqlite_utils/utils.py#L311-L316

And yes, this does indeed work - you can do something like this:

``` echo '{"name": "harry"}' | sqlite-utils insert db.db people - --convert ' import time

Simulate something expensive

time.sleep(1)

def convert(row): row["upper"] = row["name"].upper() ' And after running that: sqlite-utils dump db.db BEGIN TRANSACTION; CREATE TABLE [people] ( [name] TEXT, [upper] TEXT ); INSERT INTO "people" VALUES('harry','HARRY'); COMMIT; ``` So this is a documentation issue - there's a trick for it but I didn't know what the trick was!

Here's how the _compile_code() mechanism works at the moment: https://github.com/simonw/sqlite-utils/blob/396f80fcc60da8dd844577114f7920830a2e5403/sqlite_utils/utils.py#L308-L342

At the end it does this: python return locals["fn"] So it's already building and then returning a function.

The question is if there's a sensible way to allow people to further customize that function by executing some code first, in a way that's easy to explain.

I can think of three ways forward:

• Figure out a pattern that gets that local file import workaround to work
• Add another option such as --convert-init that lets you pass code that will be executed once at the start
• Come up with a pattern where the --convert code can run some initialization code and then return a function which will be called against each value

I quite like the idea of that third option - I'm going to prototype it and see if I can work something out.

Yeah, this is WAY harder than it should be.

There's a clumsy workaround you could use which looks something like this: create a file my_enchant.py containing:

```python import enchant d = enchant.Dict("en_US")

def check(word): return d.check(word) `` Then runsqlite-utils` like this:

PYTHONPATH=. cat items.json | jq '.data' | sqlite-utils insert listings.db listings - --convert 'my_enchant.check(value)' --import my_enchant Except I tried that and it doesn't work! I don't know the right pattern for getting --import to work with modules in the same directory.

So yeah, this is definitely a big feature gap.

would be nice if the behavior was

1. try to facet all the columns
2. for bigger tables try to facet the indexed columns
3. for the biggest tables, turn off autofacetting completely

This is based on my assumption that what determines autofaceting is the rarity of unique values. Which may not be true!

Coming back to this. I was about to add a utility function to datasette-geojson to convert lat/lng columns to geometries. Thankfully I googled first. There's a SpatiaLite function for this: MakePoint.

sql select MakePoint(longitude, latitude) as geometry from places;

I'm not sure if that would work with conversions, since it needs two columns, but it's an option for tables that already have latitude, longitude columns.

this has been addressed by the datasette-hashed-urls plugin

this has been obviated by the datasette-hashed-urls plugin