issue_comments
33 rows where "created_at" is on date 2022-02-06 sorted by html_url
This data as json, CSV (advanced)
Suggested facets: issue_url, user, author_association, reactions, issue, updated_at (date)
| id | html_url ▼ | issue_url | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1030762279 | https://github.com/simonw/datasette/issues/1176#issuecomment-1030762279 | https://api.github.com/repos/simonw/datasette/issues/1176 | IC_kwDOBm6k_c49cC8n | simonw 9599 | 2022-02-06T06:38:08Z | 2022-02-06T06:41:37Z | OWNER | Might do this using Sphinx auto-generated function and class documentation hooks, as seen here in `sqlite-utils`: https://sqlite-utils.datasette.io/en/stable/python-api.html#spatialite-helpers This would encourage me to add really good docstrings. ``` .. _python_api_gis_find_spatialite: Finding SpatiaLite ------------------ .. autofunction:: sqlite_utils.utils.find_spatialite ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Policy on documenting "public" datasette.utils functions 779691739 | |
| 1030940407 | https://github.com/simonw/datasette/issues/932#issuecomment-1030940407 | https://api.github.com/repos/simonw/datasette/issues/932 | IC_kwDOBm6k_c49cub3 | simonw 9599 | 2022-02-06T23:31:22Z | 2022-02-06T23:31:22Z | OWNER | Great argument for doing this from a conversation on Twitter about documentation-driven development: > Long ago, when the majority of commercial programs were desktop apps, I've read a very wise advice: The user manual should be written first, before even a single line if code. https://twitter.com/b11c/status/1490466703175823362 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | End-user documentation 678760988 | |
| 1030761625 | https://github.com/simonw/datasette/issues/957#issuecomment-1030761625 | https://api.github.com/repos/simonw/datasette/issues/957 | IC_kwDOBm6k_c49cCyZ | simonw 9599 | 2022-02-06T06:30:32Z | 2022-02-06T06:31:44Z | OWNER | I'm just going with: ```python from datasette import Response from datasette import Forbidden from datasette import NotFound from datasette import hookimpl from datasette import actor_matches_allow ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Simplify imports of common classes 688622148 | |
| 1030762140 | https://github.com/simonw/datasette/issues/957#issuecomment-1030762140 | https://api.github.com/repos/simonw/datasette/issues/957 | IC_kwDOBm6k_c49cC6c | simonw 9599 | 2022-02-06T06:36:41Z | 2022-02-06T06:36:41Z | OWNER | Documented here: https://docs.datasette.io/en/latest/internals.html#import-shortcuts | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Simplify imports of common classes 688622148 | |
| 1030726991 | https://github.com/simonw/sqlite-utils/issues/397#issuecomment-1030726991 | https://api.github.com/repos/simonw/sqlite-utils/issues/397 | IC_kwDOCGYnMM49b6VP | simonw 9599 | 2022-02-06T01:13:58Z | 2022-02-06T01:13:58Z | OWNER | This is a good idea. We already have that parameter for the `table.create_index()` method: https://sqlite-utils.datasette.io/en/stable/reference.html#sqlite_utils.db.Table.create_index | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support IF NOT EXISTS for table creation 1123903919 | |
| 1030727979 | https://github.com/simonw/sqlite-utils/issues/397#issuecomment-1030727979 | https://api.github.com/repos/simonw/sqlite-utils/issues/397 | IC_kwDOCGYnMM49b6kr | simonw 9599 | 2022-02-06T01:19:21Z | 2022-02-06T01:19:21Z | OWNER | Just noticed there's no explicit test coverage for the `db["table"].create(...)` method. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support IF NOT EXISTS for table creation 1123903919 | |
| 1030730108 | https://github.com/simonw/sqlite-utils/issues/397#issuecomment-1030730108 | https://api.github.com/repos/simonw/sqlite-utils/issues/397 | IC_kwDOCGYnMM49b7F8 | simonw 9599 | 2022-02-06T01:30:46Z | 2022-02-06T01:30:46Z | OWNER | Updated documentation is here: https://sqlite-utils.datasette.io/en/latest/python-api.html#explicitly-creating-a-table | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 1, "rocket": 0, "eyes": 0} | Support IF NOT EXISTS for table creation 1123903919 | |
| 1030732093 | https://github.com/simonw/sqlite-utils/issues/398#issuecomment-1030732093 | https://api.github.com/repos/simonw/sqlite-utils/issues/398 | IC_kwDOCGYnMM49b7k9 | simonw 9599 | 2022-02-06T01:41:37Z | 2022-02-06T01:41:37Z | OWNER | Yeah I'd like to avoid adding any geo-dependencies to `sqlite-utils` if I can avoid it. I'm fine using stuff that's going to be available in SpatiaLite itself (provided it's available as a SQLite module) since then I don't need to add any extra Python dependencies. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add SpatiaLite helpers to CLI 1124237013 | |
| 1030732222 | https://github.com/simonw/sqlite-utils/issues/398#issuecomment-1030732222 | https://api.github.com/repos/simonw/sqlite-utils/issues/398 | IC_kwDOCGYnMM49b7m- | simonw 9599 | 2022-02-06T01:42:19Z | 2022-02-06T01:42:28Z | OWNER | Adding some thoughts to: - #399 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add SpatiaLite helpers to CLI 1124237013 | |
| 1030732909 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030732909 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b7xt | simonw 9599 | 2022-02-06T01:47:06Z | 2022-02-06T01:47:06Z | OWNER | Here's an idea for an API design: ```python geojson_geometry = {} # ... GeoJSON goes here db["places"].insert( {"name": "Wales", "geometry": geojson_geometry}, geojson="geometry" ) ``` That `geojson=` parameter takes either a single column name or an iterable of column names. Any column in that list is expected to be a compatible `geometry` and the correct conversion functions will be applied. That solves for GeoJSON, but it's a bit ugly. Should I add `wkt=` and maybe even `kml=` and `gml=` and so-on too? Definitely not, that's way too many ugly and inscrutable new parameters. More importantly: if I want to support the following how would I do it? ```python db["places"].insert( {"name": "London", "point": (51.509865, -0.118092)} ) ``` Here I want to provide a `(latitude, longitude)` pair and have it inserted correctly into a `point` column. Could do this, but again it's messy: ```python db["places"].insert( {"name": "London", "point": (51.509865, -0.118092)}, point="point" ) ``` And again, what about those `(longitude, latitude)` people? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030735774 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030735774 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b8ee | simonw 9599 | 2022-02-06T02:08:19Z | 2022-02-06T02:08:59Z | OWNER | Maybe I should leave this entirely up to documented patterns in the `conversions={}` dictionary? But even that's not ideal for the co-ordinate case. Consider the following: ```python db["places"].insert( {"name": "London", "point": (51.509865, -0.118092)}, conversions={"point": "GeomFromText(?, 4326)"}, ) ``` The challenge here is that the SpatiaLite function `GeomFromText()` expects a WKT string, which looks like this: POINT(-0.118092 51.509865) The existing `conversions=` mechanism doesn't support applying Python code to convert the `(lat, lon)` tuple to that value. It doesn't even support passing a Python tuple as a `?` parameter - so I don't think I could come up with a SQL string that would do the right thing here either. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030736047 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030736047 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b8iv | simonw 9599 | 2022-02-06T02:10:18Z | 2022-02-06T02:10:18Z | OWNER | So maybe back to that earlier idea where the code introspects the table, figures out that `"point"` is a geometry table of type POINT, then applies the necessary conversions to the raw Python data? That feels overly-complicated to me, especially since nothing else in the `.insert()` method currently relies on table introspection. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030736589 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030736589 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b8rN | simonw 9599 | 2022-02-06T02:14:52Z | 2022-02-06T02:14:52Z | OWNER | Another idea: introduce a helper function transform pattern, something a bit like this: ```python transformer = make_transformer({ "point": lambda pair: "POINT({} {})".format(pair[1], pair[0]) }) db["places"].insert_all( transformer([{"name": "London", "point": (51.509865, -0.118092)}]) conversions={"point": "GeomFromText(?, 4326)"}, ) ``` The `make_transformer(...)` function builds an object that can work as a wrapping iterator, applying those transform functions to everything in the sequence that it wraps. So the above code would handle converting `(lat, lon)` to `POINT(lon lat)` - then the `conversions=` applies `GeomFromText`. Naming is a challenge here: `.transform()` and `.convert()` and `conversions=` all have existing meanings within the `sqlite-utils` Python library. It's also a bit of a messy way of solving this. It's not exactly a smooth API for inserting a bunch of lat/lon coordinate pairs! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030736848 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030736848 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b8vQ | simonw 9599 | 2022-02-06T02:17:35Z | 2022-02-06T02:17:35Z | OWNER | Note that GeoJSON itself uses `(longitude, latitude)` so I should probably stick to that order here too. https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.1 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030738023 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030738023 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9Bn | simonw 9599 | 2022-02-06T02:28:05Z | 2022-02-06T02:29:24Z | OWNER | Here's the definitive guide to `latitude, longitude` v.s. `longitude, latitude`: https://macwright.com/lonlat/ > Which is right? > > Neither. This is an opinion with no right answer. Geographical tradition favors lat, lon. Math and software prefer lon, lat. I asked on Twitter here: https://twitter.com/simonw/status/1490148001569906688 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030739566 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030739566 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9Zu | simonw 9599 | 2022-02-06T02:45:25Z | 2022-02-06T02:50:27Z | OWNER | Another idea - my favourite option so far: ```python from sqlite_utils.utils import LongitudeLatitude db["places"].insert( { "name": "London", "point": (-0.118092, 51.509865) }, conversions={"point": LongitudeLatitude}, ) ``` Here `LongitudeLatitude` is a magical value which does TWO things: it sets up the `GeomFromText(?, 4326)` SQL function, and it handles converting the `(51.509865, -0.118092)` tuple into a `POINT({} {})` string. This would involve a change to the `conversions=` contract - where it usually expects a SQL string fragment, but it can also take an object which combines that SQL string fragment with a Python conversion function. Best of all... this resolves the `lat, lon` v.s. `lon, lat` dilemma because you can use `from sqlite_utils.utils import LongitudeLatitude` OR `from sqlite_utils.utils import LatitudeLongitude` depending on which you prefer! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030740570 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030740570 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9pa | simonw 9599 | 2022-02-06T02:56:17Z | 2022-02-06T02:57:00Z | OWNER | Thinking about types. The type of the `conversions` parameter right now is a bit lazy: ```python conversions: Optional[dict] = None, ``` That becomes: ```python Optional[Dict[str, Union[str, Conversion]]] ``` Where `Conversion` is an abstract base class which expects implementations to have a `.sql() -> str` and a `.convert(value) -> str` method. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030740653 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030740653 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9qt | eyeseast 25778 | 2022-02-06T02:57:17Z | 2022-02-06T02:57:17Z | CONTRIBUTOR | I like the idea of having stock conversions you could import. I'd actually move them to a dedicated module (call it `sqlite_utils.conversions` or something), because it's different from other utilities. Maybe they even take configuration, or they're composable. ```python from sqlite_utils.conversions import LongitudeLatitude db["places"].insert( { "name": "London", "lng": -0.118092, "lat": 51.509865, }, conversions={"point": LongitudeLatitude("lng", "lat")}, ) ``` I would definitely use that for every CSV I get with lat/lng columns where I actually need GeoJSON. | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030740771 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030740771 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9sj | simonw 9599 | 2022-02-06T02:58:29Z | 2022-02-06T02:58:29Z | OWNER | That example you have there is really neat - I like the idea that they can also be used to populate completely new columns that are derived from the other column inputs. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030740826 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030740826 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9ta | eyeseast 25778 | 2022-02-06T02:59:10Z | 2022-02-06T02:59:10Z | CONTRIBUTOR | All this said, I don't think it's unreasonable to point people to dedicated tools like `geojson-to-sqlite`. If I'm dealing with a bunch of GeoJSON or Shapefiles, I need to something to read those anyway (or I need to figure out virtual tables). But something like this might make it easier to build those libraries, or standardize the underlying parts. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030740846 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030740846 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9tu | simonw 9599 | 2022-02-06T02:59:21Z | 2022-02-06T02:59:21Z | OWNER | I wonder if there are any interesting non-geospatial canned conversions that it would be worth including? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030740963 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030740963 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b9vj | simonw 9599 | 2022-02-06T03:00:33Z | 2022-02-06T03:00:33Z | OWNER | Yeah, having this be a general purpose mechanism which has a few canned examples for handling geospatial stuff is a lot neater than having a mechanism for this that's exclusive to SpatiaLite. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030741289 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030741289 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49b90p | eyeseast 25778 | 2022-02-06T03:03:43Z | 2022-02-06T03:03:43Z | CONTRIBUTOR | > I wonder if there are any interesting non-geospatial canned conversions that it would be worth including? Off the top of my head: - Un-nesting JSON objects into columns - Splitting arrays - Normalizing dates and times - URL munging with `urlparse` - Converting strings to numbers Some of this is easy enough with SQL functions, some is easier in Python. Maybe that's where having pre-built classes gets really handy, because it saves you from thinking about which way it's implemented. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030807433 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030807433 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49cN-J | chris48s 6025893 | 2022-02-06T10:54:09Z | 2022-02-06T10:54:09Z | NONE | > Interesting that some accept an SRID and others do not - presumably GeomFromGeoJSON() always uses SRID=4326? The ewtk/ewkb ones don't accept an SRID is because ewkt encodes the SRID in the string, so you would do this with a wkt string: `GeomFromText('POINT(529090 179645)', 27700)` but for ewkt it would be `GeomFromEWKT('SRID=27700;POINT(529090 179645)')` The specs for KML and GeoJSON specify a Coordinate Reference System for the format - https://datatracker.ietf.org/doc/html/rfc7946#section-4 - https://docs.opengeospatial.org/is/12-007r2/12-007r2.html#1274 GML can specify the SRID in the XML at feature level e.g: ``` <gml:Point srsName="EPSG:27700"> <gml:coordinates>529090, 179645</gml:coordinates> </gml:Point> ``` There's a few more obscure formats in there, but broadly I think it is safe to assume an SRID param exists on the function for cases where the SRID is not implied by or specified in the input format. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030871591 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030871591 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49cdon | simonw 9599 | 2022-02-06T16:57:22Z | 2022-02-06T16:57:22Z | OWNER | I wonder if I could implement the above such that this *also* works: ```python db["places"].insert( { "name": "London", "point": LongitudeLatitude(-0.118092, 51.509865) } ) ``` This feels like a very natural way to work with single inserts. The challenge is writing the code inside `.insert_all()` such that it can handle these special objects in the input column values in addition to them being passed in `conversions=`. I'm feeling very good about this direction in general though, it feels like it takes the existing but not particularly elegant `conversions=` mechanism and upgrades it to be far more useful, while maintaining backwards compatibility. | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 1} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030902158 | https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030902158 | https://api.github.com/repos/simonw/sqlite-utils/issues/399 | IC_kwDOCGYnMM49clGO | simonw 9599 | 2022-02-06T19:53:54Z | 2022-02-06T19:53:54Z | OWNER | Moving the design of this new `Conversion` subclass mechanism to: - https://github.com/simonw/sqlite-utils/issues/402 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Make it easier to insert geometries, with documentation and maybe code 1124731464 | |
| 1030730748 | https://github.com/simonw/sqlite-utils/issues/400#issuecomment-1030730748 | https://api.github.com/repos/simonw/sqlite-utils/issues/400 | IC_kwDOCGYnMM49b7P8 | simonw 9599 | 2022-02-06T01:34:46Z | 2022-02-06T01:34:46Z | OWNER | Actually this is not needed - there is already an option that does this, it's just called `--ignore` rather than `--if-not-exists`. The lack of consistency here is a little annoying, but not annoying enough to justify making a backwards incompatible change. ``` % sqlite-utils create-table --help Usage: sqlite-utils create-table [OPTIONS] PATH TABLE COLUMNS... Add a table with the specified columns. Columns should be specified using name, type pairs, for example: sqlite-utils create-table my.db people \ id integer \ name text \ height float \ photo blob --pk id Options: --pk TEXT Column to use as primary key --not-null TEXT Columns that should be created as NOT NULL --default <TEXT TEXT>... Default value that should be set for a column --fk <TEXT TEXT TEXT>... Column, other table, other column to set as a foreign key --ignore If table already exists, do nothing --replace If table already exists, replace it --load-extension TEXT SQLite extensions to load -h, --help Show this message and exit. ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | `sqlite-utils create-table` ... `--if-not-exists` 1125077063 | |
| 1030734937 | https://github.com/simonw/sqlite-utils/issues/401#issuecomment-1030734937 | https://api.github.com/repos/simonw/sqlite-utils/issues/401 | IC_kwDOCGYnMM49b8RZ | simonw 9599 | 2022-02-06T02:02:24Z | 2022-02-06T02:02:24Z | OWNER | The example also doesn't work right now - the code that fetches from Who's On First gets a 403 forbidden error. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update SpatiaLite example in the documentation 1125081640 | |
| 1030735372 | https://github.com/simonw/sqlite-utils/issues/401#issuecomment-1030735372 | https://api.github.com/repos/simonw/sqlite-utils/issues/401 | IC_kwDOCGYnMM49b8YM | simonw 9599 | 2022-02-06T02:05:03Z | 2022-02-06T02:05:03Z | OWNER | Improved version: https://sqlite-utils.datasette.io/en/latest/python-api.html#converting-column-values-using-sql-functions | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update SpatiaLite example in the documentation 1125081640 | |
| 1030901189 | https://github.com/simonw/sqlite-utils/issues/402#issuecomment-1030901189 | https://api.github.com/repos/simonw/sqlite-utils/issues/402 | IC_kwDOCGYnMM49ck3F | simonw 9599 | 2022-02-06T19:48:36Z | 2022-02-06T19:48:52Z | OWNER | From [that thread](https://github.com/simonw/sqlite-utils/issues/399#issuecomment-1030739566), two extra ideas which it may be possible to support in a single implementation: ```python from sqlite_utils.conversions import LongitudeLatitude db["places"].insert( { "name": "London", "lng": -0.118092, "lat": 51.509865, }, conversions={"point": LongitudeLatitude("lng", "lat")}, ) ``` And ```python db["places"].insert( { "name": "London", "point": LongitudeLatitude(-0.118092, 51.509865) } ) ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Advanced class-based `conversions=` mechanism 1125297737 | |
| 1030901853 | https://github.com/simonw/sqlite-utils/issues/402#issuecomment-1030901853 | https://api.github.com/repos/simonw/sqlite-utils/issues/402 | IC_kwDOCGYnMM49clBd | simonw 9599 | 2022-02-06T19:52:10Z | 2022-02-06T19:52:10Z | OWNER | So the key idea here is to introduce a new abstract base class, `Conversion`, which has the following abilities: - Can wrap one or more Python values (if called using the constructor) such that the `.insert_all()` method knows how to transform those into a format that can be included in an insert - something like `GeomFromText(?, 4326)` with input `POINT(-0.118092 51.509865)` - Can be passed to `conversions={"point": LongitudeLatitude}` in a way that then knows to apply that conversion to every value in the `"point"` key of the data being inserted. - Maybe also extend `conversions=` to allow the definition of additional keys that use as input other rows? That's the `conversions={"point": LongitudeLatitude("lng", "lat")}` example above - it may not be possible to get this working with the rest of the design though. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Advanced class-based `conversions=` mechanism 1125297737 | |
| 1030902102 | https://github.com/simonw/sqlite-utils/issues/402#issuecomment-1030902102 | https://api.github.com/repos/simonw/sqlite-utils/issues/402 | IC_kwDOCGYnMM49clFW | simonw 9599 | 2022-02-06T19:53:34Z | 2022-02-08T07:40:34Z | OWNER | I like the idea that the contract for `Conversion` (or rather for its subclasses) is that it can wrap a Python value and then return both the SQL fragment - e.g. `GeomFromText(?, 4326)` - and the values that should be used as the SQL parameters. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Advanced class-based `conversions=` mechanism 1125297737 | |
| 1030904948 | https://github.com/simonw/sqlite-utils/issues/402#issuecomment-1030904948 | https://api.github.com/repos/simonw/sqlite-utils/issues/402 | IC_kwDOCGYnMM49clx0 | simonw 9599 | 2022-02-06T20:09:42Z | 2022-02-08T07:40:44Z | OWNER | I think this is the code that needs to become aware of this system: https://github.com/simonw/sqlite-utils/blob/fea8c9bcc509bcae75e99ae8870f520103b9aa58/sqlite_utils/db.py#L2453-L2469 There's an earlier branch that runs for upserts which needs to be modified too: https://github.com/simonw/sqlite-utils/blob/fea8c9bcc509bcae75e99ae8870f520103b9aa58/sqlite_utils/db.py#L2417-L2440 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Advanced class-based `conversions=` mechanism 1125297737 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] (
[html_url] TEXT,
[issue_url] TEXT,
[id] INTEGER PRIMARY KEY,
[node_id] TEXT,
[user] INTEGER REFERENCES [users]([id]),
[created_at] TEXT,
[updated_at] TEXT,
[author_association] TEXT,
[body] TEXT,
[reactions] TEXT,
[issue] INTEGER REFERENCES [issues]([id])
, [performed_via_github_app] TEXT);
CREATE INDEX [idx_issue_comments_issue]
ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
ON [issue_comments] ([user]);
created_at (date) 1 ✖