issue_comments
563 rows where author_association = "CONTRIBUTOR" sorted by user descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
id | html_url | issue_url | node_id | user ▲ | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
---|---|---|---|---|---|---|---|---|---|---|---|
1261930179 | https://github.com/simonw/datasette/issues/370#issuecomment-1261930179 | https://api.github.com/repos/simonw/datasette/issues/370 | IC_kwDOBm6k_c5LN4bD | MichaelTiemannOSC 72577720 | 2022-09-29T08:17:46Z | 2022-09-29T08:17:46Z | CONTRIBUTOR | Just watched this video which demonstrates the integration of *any* webapp into JupyterLab: https://youtu.be/FH1dKKmvFtc Maybe this is the answer? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Integration with JupyterLab 377155320 | |
946467547 | https://github.com/simonw/datasette/issues/1396#issuecomment-946467547 | https://api.github.com/repos/simonw/datasette/issues/1396 | IC_kwDOBm6k_c44afLb | MichaelTiemannOSC 72577720 | 2021-10-19T08:10:26Z | 2021-10-19T08:10:26Z | CONTRIBUTOR | Now that 0.59 has excellent annotated release notes, you can re-confirm this is fixed by updating the published Docker image and checking that these fixes still work ;-) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | "invalid reference format" publishing Docker image 944903881 | |
1547911570 | https://github.com/simonw/datasette/pull/2068#issuecomment-1547911570 | https://api.github.com/repos/simonw/datasette/issues/2068 | IC_kwDOBm6k_c5cQ0GS | dependabot[bot] 49699333 | 2023-05-15T13:59:35Z | 2023-05-15T13:59:35Z | CONTRIBUTOR | Superseded by #2075. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 6.1.3 to 7.0.0 1690842199 | |
1529737426 | https://github.com/simonw/datasette/pull/2064#issuecomment-1529737426 | https://api.github.com/repos/simonw/datasette/issues/2064 | IC_kwDOBm6k_c5bLfDS | dependabot[bot] 49699333 | 2023-05-01T13:58:50Z | 2023-05-01T13:58:50Z | CONTRIBUTOR | Superseded by #2068. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 6.1.3 to 6.2.1 1683229834 | |
1521837780 | https://github.com/simonw/datasette/pull/2063#issuecomment-1521837780 | https://api.github.com/repos/simonw/datasette/issues/2063 | IC_kwDOBm6k_c5atWbU | dependabot[bot] 49699333 | 2023-04-25T13:57:52Z | 2023-04-25T13:57:52Z | CONTRIBUTOR | Superseded by #2064. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 6.1.3 to 6.2.0 1681339696 | |
1487999503 | https://github.com/simonw/datasette/pull/2014#issuecomment-1487999503 | https://api.github.com/repos/simonw/datasette/issues/2014 | IC_kwDOBm6k_c5YsRIP | dependabot[bot] 49699333 | 2023-03-29T06:09:11Z | 2023-03-29T06:09:11Z | CONTRIBUTOR | Superseded by #2047. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 22.12.0 to 23.1.0 1566081801 | |
1486944644 | https://github.com/simonw/datasette/pull/2043#issuecomment-1486944644 | https://api.github.com/repos/simonw/datasette/issues/2043 | IC_kwDOBm6k_c5YoPmE | dependabot[bot] 49699333 | 2023-03-28T13:58:20Z | 2023-03-28T13:58:20Z | CONTRIBUTOR | Superseded by #2046. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump furo from 2022.12.7 to 2023.3.23 1639446870 | |
1376620851 | https://github.com/simonw/datasette/pull/1982#issuecomment-1376620851 | https://api.github.com/repos/simonw/datasette/issues/1982 | IC_kwDOBm6k_c5SDZEz | dependabot[bot] 49699333 | 2023-01-10T02:03:18Z | 2023-01-10T02:03:18Z | CONTRIBUTOR | Looks like sphinx is up-to-date now, so this is no longer needed. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 5.3.0 to 6.1.2 1525560504 | |
1375596856 | https://github.com/simonw/datasette/pull/1977#issuecomment-1375596856 | https://api.github.com/repos/simonw/datasette/issues/1977 | IC_kwDOBm6k_c5R_fE4 | dependabot[bot] 49699333 | 2023-01-09T13:06:14Z | 2023-01-09T13:06:14Z | CONTRIBUTOR | Superseded by #1982. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 5.3.0 to 6.1.1 1522552817 | |
1373592231 | https://github.com/simonw/datasette/pull/1976#issuecomment-1373592231 | https://api.github.com/repos/simonw/datasette/issues/1976 | IC_kwDOBm6k_c5R31qn | dependabot[bot] 49699333 | 2023-01-06T13:02:15Z | 2023-01-06T13:02:15Z | CONTRIBUTOR | Superseded by #1977. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 5.3.0 to 6.1.0 1520712722 | |
1372188571 | https://github.com/simonw/datasette/pull/1974#issuecomment-1372188571 | https://api.github.com/repos/simonw/datasette/issues/1974 | IC_kwDOBm6k_c5Rye-b | dependabot[bot] 49699333 | 2023-01-05T13:02:40Z | 2023-01-05T13:02:40Z | CONTRIBUTOR | Superseded by #1976. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump sphinx from 5.3.0 to 6.0.0 1516376583 | |
1237381620 | https://github.com/simonw/datasette/pull/1685#issuecomment-1237381620 | https://api.github.com/repos/simonw/datasette/issues/1685 | IC_kwDOBm6k_c5JwPH0 | dependabot[bot] 49699333 | 2022-09-05T18:36:47Z | 2022-09-05T18:36:47Z | CONTRIBUTOR | Looks like jinja2 is no longer updatable, so this is no longer needed. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update jinja2 requirement from <3.1.0,>=2.10.3 to >=2.10.3,<3.2.0 1180778860 | |
1237381569 | https://github.com/simonw/datasette/pull/1799#issuecomment-1237381569 | https://api.github.com/repos/simonw/datasette/issues/1799 | IC_kwDOBm6k_c5JwPHB | dependabot[bot] 49699333 | 2022-09-05T18:36:42Z | 2022-09-05T18:36:42Z | CONTRIBUTOR | Looks like aiofiles is no longer updatable, so this is no longer needed. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update aiofiles requirement from <0.9,>=0.4 to >=0.4,<22.2 1362242558 | |
1168704157 | https://github.com/simonw/datasette/pull/1693#issuecomment-1168704157 | https://api.github.com/repos/simonw/datasette/issues/1693 | IC_kwDOBm6k_c5FqQKd | dependabot[bot] 49699333 | 2022-06-28T13:11:36Z | 2022-06-28T13:11:36Z | CONTRIBUTOR | Superseded by #1763. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 22.1.0 to 22.3.0 1184850337 | |
1163091750 | https://github.com/simonw/datasette/pull/1753#issuecomment-1163091750 | https://api.github.com/repos/simonw/datasette/issues/1753 | IC_kwDOBm6k_c5FU18m | dependabot[bot] 49699333 | 2022-06-22T13:22:34Z | 2022-06-22T13:22:34Z | CONTRIBUTOR | Superseded by #1760. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump furo from 2022.4.7 to 2022.6.4.1 1261826957 | |
1031455498 | https://github.com/simonw/datasette/pull/1593#issuecomment-1031455498 | https://api.github.com/repos/simonw/datasette/issues/1593 | IC_kwDOBm6k_c49esMK | dependabot[bot] 49699333 | 2022-02-07T13:13:22Z | 2022-02-07T13:13:22Z | CONTRIBUTOR | Superseded by #1631. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update pytest-asyncio requirement from <0.17,>=0.10 to >=0.10,<0.18 1101705012 | |
972852184 | https://github.com/simonw/datasette/pull/1514#issuecomment-972852184 | https://api.github.com/repos/simonw/datasette/issues/1514 | IC_kwDOBm6k_c45_IvY | dependabot[bot] 49699333 | 2021-11-18T13:11:15Z | 2021-11-18T13:11:15Z | CONTRIBUTOR | Superseded by #1516. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 21.9b0 to 21.11b0 1056117435 | |
971568829 | https://github.com/simonw/datasette/pull/1500#issuecomment-971568829 | https://api.github.com/repos/simonw/datasette/issues/1500 | IC_kwDOBm6k_c456Pa9 | dependabot[bot] 49699333 | 2021-11-17T13:13:58Z | 2021-11-17T13:13:58Z | CONTRIBUTOR | Superseded by #1514. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 21.9b0 to 21.10b0 1041158024 | |
943594738 | https://github.com/simonw/datasette/pull/1489#issuecomment-943594738 | https://api.github.com/repos/simonw/datasette/issues/1489 | IC_kwDOBm6k_c44Phzy | dependabot[bot] 49699333 | 2021-10-14T18:04:13Z | 2021-10-14T18:04:13Z | CONTRIBUTOR | OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update pyyaml requirement from ~=5.3 to >=5.3,<7.0 1026379132 | |
943594735 | https://github.com/simonw/datasette/pull/1489#issuecomment-943594735 | https://api.github.com/repos/simonw/datasette/issues/1489 | IC_kwDOBm6k_c44Phzv | dependabot[bot] 49699333 | 2021-10-14T18:04:12Z | 2021-10-14T18:04:12Z | CONTRIBUTOR | Looks like this PR is closed. If you re-open it I'll rebase it as long as no-one else has edited it (you can use `@dependabot reopen` if the branch has been deleted). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update pyyaml requirement from ~=5.3 to >=5.3,<7.0 1026379132 | |
919135732 | https://github.com/simonw/datasette/pull/1453#issuecomment-919135732 | https://api.github.com/repos/simonw/datasette/issues/1453 | IC_kwDOBm6k_c42yOX0 | dependabot[bot] 49699333 | 2021-09-14T13:10:38Z | 2021-09-14T13:10:38Z | CONTRIBUTOR | Superseded by #1471. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 21.7b0 to 21.8b0 982780906 | |
838449572 | https://github.com/simonw/datasette/pull/1318#issuecomment-838449572 | https://api.github.com/repos/simonw/datasette/issues/1318 | MDEyOklzc3VlQ29tbWVudDgzODQ0OTU3Mg== | dependabot[bot] 49699333 | 2021-05-11T13:12:30Z | 2021-05-11T13:12:30Z | CONTRIBUTOR | Superseded by #1321. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 21.4b2 to 21.5b0 876431852 | |
934372104 | https://github.com/dogsheep/dogsheep-photos/issues/3#issuecomment-934372104 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/3 | IC_kwDOD079W843sWMI | RhetTbull 41546558 | 2021-10-05T12:38:24Z | 2021-10-05T12:38:24Z | CONTRIBUTOR | As dogsheep-photos already uses [osxphotos](https://github.com/RhetTbull/osxphotos) to load photos you can access the EXIF data via osxphotos. Apple Photos imports a small subset of EXIF data at the time the photo is imported and osxphotos provides this via the [exif_info](https://github.com/RhetTbull/osxphotos#exifinfo) property. If you want the full EXIF data, osxphotos also provides a wrapper around [exiftool](https://github.com/RhetTbull/osxphotos#exiftool). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Import EXIF data into SQLite - lens used, ISO, aperture etc 602533481 | |
778246347 | https://github.com/dogsheep/dogsheep-photos/issues/33#issuecomment-778246347 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/33 | MDEyOklzc3VlQ29tbWVudDc3ODI0NjM0Nw== | RhetTbull 41546558 | 2021-02-12T15:00:43Z | 2021-02-12T15:00:43Z | CONTRIBUTOR | Yes, Big Sur Photos database doesn't have `ZGENERICASSET` table. PR #31 will fix this. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | photo-to-sqlite: command not found 803338729 | |
748562330 | https://github.com/dogsheep/dogsheep-photos/pull/31#issuecomment-748562330 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/31 | MDEyOklzc3VlQ29tbWVudDc0ODU2MjMzMA== | RhetTbull 41546558 | 2020-12-20T04:45:08Z | 2020-12-20T04:45:08Z | CONTRIBUTOR | Fixes the issue mentioned here: https://github.com/dogsheep/dogsheep-photos/issues/15#issuecomment-748436115 | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 1, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update for Big Sur 771511344 | |
748562288 | https://github.com/dogsheep/dogsheep-photos/issues/15#issuecomment-748562288 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/15 | MDEyOklzc3VlQ29tbWVudDc0ODU2MjI4OA== | RhetTbull 41546558 | 2020-12-20T04:44:22Z | 2020-12-20T04:44:22Z | CONTRIBUTOR | @nickvazz @simonw I opened a [PR](https://github.com/dogsheep/dogsheep-photos/pull/31) that replaces the SQL for `ZCOMPUTEDASSETATTRIBUTES` to use osxphotos which now exposes all this data and has been updated for Big Sur. I did regression tests to confirm the extracted data is identical, with one exception which should not affect operation: the old code pulled data from `ZCOMPUTEDASSETATTRIBUTES` for missing photos while the main loop ignores missing photos and does not add them to `apple_photos`. The new code does not add rows to the `apple_photos_scores` table for missing photos. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Expose scores from ZCOMPUTEDASSETATTRIBUTES 612151767 | |
748436779 | https://github.com/dogsheep/dogsheep-photos/issues/15#issuecomment-748436779 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/15 | MDEyOklzc3VlQ29tbWVudDc0ODQzNjc3OQ== | RhetTbull 41546558 | 2020-12-19T07:49:00Z | 2020-12-19T07:49:00Z | CONTRIBUTOR | @nickvazz ZGENERICASSET changed to ZASSET in Big Sur. Here's a list of other changes to the schema in Big Sur: https://github.com/RhetTbull/osxphotos/wiki/Changes-in-Photos-6---Big-Sur | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Expose scores from ZCOMPUTEDASSETATTRIBUTES 612151767 | |
628405453 | https://github.com/dogsheep/dogsheep-photos/issues/22#issuecomment-628405453 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/22 | MDEyOklzc3VlQ29tbWVudDYyODQwNTQ1Mw== | RhetTbull 41546558 | 2020-05-14T05:59:53Z | 2020-05-14T05:59:53Z | CONTRIBUTOR | I've added support for the above exif data to [v0.28.17](https://github.com/RhetTbull/osxphotos/releases/tag/v0.28.17) of osxphotos. `PhotoInfo.exif_info` will return an `ExifInfo` [dataclass](https://docs.python.org/3/library/dataclasses.html) object with the following properties: ```python flash_fired: bool iso: int metering_mode: int sample_rate: int track_format: int white_balance: int aperture: float bit_rate: float duration: float exposure_bias: float focal_length: float fps: float latitude: float longitude: float shutter_speed: float camera_make: str camera_model: str codec: str lens_model: str ``` It's not all the EXIF data available in most files but is the data Photos deems important to save. Of course, you can get all the exif_data Note: this only works in Photos 5. As best as I can tell, EXIF data is not stored in the database for earlier versions. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Try out ExifReader 615626118 | |
627007458 | https://github.com/dogsheep/dogsheep-photos/issues/22#issuecomment-627007458 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/22 | MDEyOklzc3VlQ29tbWVudDYyNzAwNzQ1OA== | RhetTbull 41546558 | 2020-05-11T22:51:52Z | 2020-05-11T22:52:26Z | CONTRIBUTOR | I'm not familiar with `ExifReader`. I wrote my own wrapper around `exiftool` because I wanted a simple way to write EXIF data when exporting photos (e.g. writing out to PersonInImage and keywords to IPTC:Keywords) and the existing python packages like [pyexiftool](https://github.com/smarnach/pyexiftool) didn't do quite what I wanted. If all you're after is the camera and shot info, that's available in `ZEXTENDEDATTRIBUTES` table. I've got an open issue [#11](https://github.com/RhetTbull/osxphotos/issues/11) to add this to osxphotos but it hasn't bubbled to the top of my backlog yet. osxphotos will give you the location info: `PhotoInfo.location` returns a tuple of (lat, lon) though this info is in ZEXTENDEDATTRIBUTES too (though it might not be correct as I believe Photos creates this table at import and the user might have changed the location of a photo, e.g. if camera didn't have GPS). ```sql CREATE TABLE ZEXTENDEDATTRIBUTES ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZFLASHFIRED INTEGER, ZISO INTEGER, ZMETERINGMODE INTEGER, ZSAMPLERATE INTEGER, ZTRACKFORMAT INTEGER, ZWHITEBALANCE INTEGER, ZASSET INTEGER, ZAPERTURE FLOAT, ZBITRATE FLOAT, ZDURATION FLOAT, ZEXPOSUREBIAS FLOAT, ZFOCALLENGTH FLOAT, ZFPS FLOAT, ZLATITUDE FLOAT, ZLONGITUDE FLOAT, ZSHUTTERSPEED FLOAT, ZCAMERAMAKE VARCHAR, ZCAMERAMODEL VARCHAR, ZCODEC VARCHAR, ZLENSMODEL VARCHAR ); ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Try out ExifReader 615626118 | |
626667235 | https://github.com/dogsheep/dogsheep-photos/issues/22#issuecomment-626667235 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/22 | MDEyOklzc3VlQ29tbWVudDYyNjY2NzIzNQ== | RhetTbull 41546558 | 2020-05-11T12:20:34Z | 2020-05-11T12:20:34Z | CONTRIBUTOR | @simonw FYI, osxphotos includes a built in ExifTool class that uses [exiftool](https://exiftool.org/) to read and write exif data. It's not exposed yet in the docs because I really only use it right now in the osphotos command line interface to write tags when exporting. In v0.28.16 (just pushed) I added an ExifTool.as_dict() method which will give you a dict with all the exif tags in a file. For example: ```python import osxphotos photos = osxphotos.PhotosDB().photos() exiftool = osxphotos.exiftool.ExifTool(photos[0].path) exifdata = exiftool.as_dict() tags = exifdata["IPTC:Keywords"] ``` Not as elegant perhaps as a python only implementation because ExifTool has to make subprocess calls to an external tool but exiftool is by far the best tool available for reading and writing EXIF data and it does support HEIC. As for implementation, ExifTool uses a singleton pattern so the first time you instantiate it, it spawns an IPC to exiftool but then keeps it open and uses the same process for any subsequent calls (even on different files). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Try out ExifReader 615626118 | |
626396379 | https://github.com/dogsheep/dogsheep-photos/issues/21#issuecomment-626396379 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/21 | MDEyOklzc3VlQ29tbWVudDYyNjM5NjM3OQ== | RhetTbull 41546558 | 2020-05-10T22:01:48Z | 2020-05-10T22:01:48Z | CONTRIBUTOR | Frustrates me when package authors create a "drop in" replacement with the same import name...this kind of thing has bitten me more than once! Would've been nicer I think for bpylist2 to do "import bpylist2 as bpylist" | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | bpylist.archiver.CircularReference: archive has a cycle with uid(13) 615474990 | |
626395641 | https://github.com/dogsheep/dogsheep-photos/issues/21#issuecomment-626395641 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/21 | MDEyOklzc3VlQ29tbWVudDYyNjM5NTY0MQ== | RhetTbull 41546558 | 2020-05-10T21:55:54Z | 2020-05-10T21:55:54Z | CONTRIBUTOR | Did removing old bpylist solve the original problem or do you still have a photo that throws circular reference? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | bpylist.archiver.CircularReference: archive has a cycle with uid(13) 615474990 | |
626395507 | https://github.com/dogsheep/dogsheep-photos/issues/21#issuecomment-626395507 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/21 | MDEyOklzc3VlQ29tbWVudDYyNjM5NTUwNw== | RhetTbull 41546558 | 2020-05-10T21:54:45Z | 2020-05-10T21:54:45Z | CONTRIBUTOR | @simonw does Photos show valid reverse geolocation info? Are you sure you're using [bpylist2](https://github.com/xa4a/bpylist2) and not bpylist? They're both unfortunately imported as "bpylist" so if you somehow got the wrong (original bpylist) version installed, it could be the issue. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | bpylist.archiver.CircularReference: archive has a cycle with uid(13) 615474990 | |
626390317 | https://github.com/dogsheep/dogsheep-photos/issues/21#issuecomment-626390317 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/21 | MDEyOklzc3VlQ29tbWVudDYyNjM5MDMxNw== | RhetTbull 41546558 | 2020-05-10T21:11:24Z | 2020-05-10T21:50:58Z | CONTRIBUTOR | Ugh....Yeah, I think easiest is to catch the exception and return no place as you suggest. This particular bit of code involves un-archiving a serialized NSKeyedArchiver which uses an object table and it is certainly possible to create a circular reference that way. Because this is happening in the decode, the circular reference must be in the original data. Does Photos show valid reverse geolocation info for the photo in question? If so, Photos may be doing something beyond a simple decode of the binary plist. For now, I'll push a patch to catch the exception. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | bpylist.archiver.CircularReference: archive has a cycle with uid(13) 615474990 | |
624284539 | https://github.com/dogsheep/dogsheep-photos/issues/17#issuecomment-624284539 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/17 | MDEyOklzc3VlQ29tbWVudDYyNDI4NDUzOQ== | RhetTbull 41546558 | 2020-05-05T20:20:05Z | 2020-05-05T20:20:05Z | CONTRIBUTOR | FYI, I've got an [issue](https://github.com/RhetTbull/osxphotos/issues/25) to make osxphotos cross-platform but it's low on my priority list. About 90% of the functionality could be done cross-platform but right now the MacOS specific stuff is embedded throughout and would take some work. Though I try to minimize it, there's sprinklings of ObjC & Applescript throughout osxphotos. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Only install osxphotos if running on macOS 612860531 | |
623845014 | https://github.com/dogsheep/dogsheep-photos/issues/16#issuecomment-623845014 | https://api.github.com/repos/dogsheep/dogsheep-photos/issues/16 | MDEyOklzc3VlQ29tbWVudDYyMzg0NTAxNA== | RhetTbull 41546558 | 2020-05-05T03:55:14Z | 2020-05-05T03:56:24Z | CONTRIBUTOR | I'm traveling w/o access to my Mac so can't help with any code right now. I suspected ZSCENEIDENTIFIER was a foreign key into one of these psi.sqlite tables. But looks like you're on to something connecting groups to assets. As for the UUID, I think there's two ints because each is 64-bits but UUIDs are 128-bits. Thus they need to be combined to get the 128 bit UUID. You might be able to use Apple's [NSUUID](https://developer.apple.com/documentation/foundation/nsuuid?language=objc), for example, by wrapping with pyObjC. Here's one [example](https://github.com/ronaldoussoren/pyobjc/blob/881c82a7ba90f193934b52b44143360c80dce5e5/pyobjc-framework-Cocoa/PyObjCTest/test_nsuuid.py) of using this in PyObjC's test suite. Interesting it's stored this way instead of a UUIDString as in Photos.sqlite. Perhaps it for faster indexing. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Import machine-learning detected labels (dog, llama etc) from Apple Photos 612287234 | |
622599528 | https://github.com/simonw/sqlite-utils/issues/103#issuecomment-622599528 | https://api.github.com/repos/simonw/sqlite-utils/issues/103 | MDEyOklzc3VlQ29tbWVudDYyMjU5OTUyOA== | b0b5h4rp13 32605365 | 2020-05-01T22:49:12Z | 2020-05-02T11:15:44Z | CONTRIBUTOR | With SQLITE_MAX_VARS = 999, or even 899, This hits the problem with the batch rows causing a overflow (works fine if SQLITE_MAX_VARS = 799). p.s. I have tried a few list of dicts to sqlite modules and this was the easiest to use/understand ------------- file begins ------------------ import sqlite_utils as su data = [ {'tickerId': 913324382, 'exchangeId': 11, 'type': 2, 'secType': 61, 'regionId': 6, 'regionCode': 'US', 'currencyId': 247, 'name': 'CONSTELLATION B', 'symbol': 'STZ B', 'disSymbol': 'STZ-B', 'disExchangeCode': 'NYSE', 'exchangeCode': 'NYSE', 'listStatus': 1, 'template': 'stock', 'status': 'D', 'close': '163.13', 'change': '6.46', 'changeRatio': '0.0412', 'marketValue': '31180699895.63', 'volume': '417', 'turnoverRate': '0.0000'}, {'tickerId': 913323791, 'exchangeId': 11, 'type': 2, 'secType': 61, 'regionId': 6, 'regionCode': 'US', 'currencyId': 247, 'name': 'Molina Health', 'symbol': 'MOH', 'disSymbol': 'MOH', 'disExchangeCode': 'NYSE', 'exchangeCode': 'NYSE', 'listStatus': 1, 'template': 'stock', 'derivativeSupport': 1, 'status': 'D', 'close': '173.25', 'change': '9.28', 'changeRatio': '0.0566', 'pPrice': '173.25', 'pChange': '0.0000', 'pChRatio': '0.0000', 'marketValue': '10520341695.50', 'volume': '1281557', 'turnoverRate': '0.0202'}, {'tickerId': 913257501, 'exchangeId': 96, 'type': 2, 'secType': 61, 'regionId': 6, 'regionCode': 'US', 'currencyId': 247, 'name': 'Seattle Genetics', 'symbol': 'SGEN', 'disSymbol': 'SGEN', 'disExchangeCode': 'NASDAQ', 'exchangeCode': 'NSQ', 'listStatus': 1, 'template': 'stock', 'derivativeSupport': 1, 'status': 'A', 'close': '145.64', 'change': '8.41', 'changeRatio': '0.0613', 'pPrice': '146.45', 'pChange': '0.8100', 'pChRatio': '0.0056', 'marketValue': '25117961347.60', 'volume': '2791411', 'turnoverRate': '0.0162'}, {'tickerId': 925381971, 'exchangeId': 96, 'type': 2, 'secType': 61, 'regionId': 6, 'regionCode': 'US', 'currencyId': 247, 'name': 'Bandwidth', 'symbol': 'BAND', 'disSymbol': 'BAND', 'disExchangeCode': 'NASDAQ', 'exchangeCode': 'NSQ', '… | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | sqlite3.OperationalError: too many SQL variables in insert_all when using rows with varying numbers of columns 610517472 | |
661524006 | https://github.com/simonw/datasette/issues/456#issuecomment-661524006 | https://api.github.com/repos/simonw/datasette/issues/456 | MDEyOklzc3VlQ29tbWVudDY2MTUyNDAwNg== | abeyerpath 32467826 | 2020-07-21T01:15:07Z | 2020-07-21T01:15:07Z | CONTRIBUTOR | Bumping this, as the previous fix is passing the wrong type, and not actually addressing the issue... The `exclude` argument needs an iterable of packages instead of a single string (but since `str` is iterable, it's currently excluding packages `t`, `e`, and `s`.) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Installing installs the tests package 442327592 | |
707326192 | https://github.com/dogsheep/swarm-to-sqlite/pull/10#issuecomment-707326192 | https://api.github.com/repos/dogsheep/swarm-to-sqlite/issues/10 | MDEyOklzc3VlQ29tbWVudDcwNzMyNjE5Mg== | mattiaborsoi 29426418 | 2020-10-12T20:20:02Z | 2020-10-12T20:20:02Z | CONTRIBUTOR | This closes issue #8 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update utils.py to fix sqlite3.OperationalError 719637258 | |
829352402 | https://github.com/simonw/datasette/pull/1313#issuecomment-829352402 | https://api.github.com/repos/simonw/datasette/issues/1313 | MDEyOklzc3VlQ29tbWVudDgyOTM1MjQwMg== | dependabot-preview[bot] 27856297 | 2021-04-29T15:47:23Z | 2021-04-29T15:47:23Z | CONTRIBUTOR | This pull request will no longer be automatically closed when a new version is found as this pull request was created by Dependabot Preview and this repo is using a `version: 2` config file. You can close this pull request and let Dependabot re-create it the next time it checks for updates. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 20.8b1 to 21.4b2 871046111 | |
829260725 | https://github.com/simonw/datasette/pull/1311#issuecomment-829260725 | https://api.github.com/repos/simonw/datasette/issues/1311 | MDEyOklzc3VlQ29tbWVudDgyOTI2MDcyNQ== | dependabot-preview[bot] 27856297 | 2021-04-29T13:58:08Z | 2021-04-29T13:58:08Z | CONTRIBUTOR | Superseded by #1313. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 20.8b1 to 21.4b1 870227815 | |
828679943 | https://github.com/simonw/datasette/pull/1309#issuecomment-828679943 | https://api.github.com/repos/simonw/datasette/issues/1309 | MDEyOklzc3VlQ29tbWVudDgyODY3OTk0Mw== | dependabot-preview[bot] 27856297 | 2021-04-28T18:26:03Z | 2021-04-28T18:26:03Z | CONTRIBUTOR | Superseded by #1311. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Bump black from 20.8b1 to 21.4b0 869237023 | |
686061028 | https://github.com/simonw/datasette/pull/952#issuecomment-686061028 | https://api.github.com/repos/simonw/datasette/issues/952 | MDEyOklzc3VlQ29tbWVudDY4NjA2MTAyOA== | dependabot-preview[bot] 27856297 | 2020-09-02T22:26:14Z | 2020-09-02T22:26:14Z | CONTRIBUTOR | Looks like black is up-to-date now, so this is no longer needed. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update black requirement from ~=19.10b0 to >=19.10,<21.0 687245650 | |
623463200 | https://github.com/simonw/datasette/pull/730#issuecomment-623463200 | https://api.github.com/repos/simonw/datasette/issues/730 | MDEyOklzc3VlQ29tbWVudDYyMzQ2MzIwMA== | dependabot-preview[bot] 27856297 | 2020-05-04T13:27:22Z | 2020-05-04T13:27:22Z | CONTRIBUTOR | Superseded by #753. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Update pytest-asyncio requirement from ~=0.10.0 to >=0.10,<0.12 604001627 | |
770150526 | https://github.com/dogsheep/github-to-sqlite/issues/51#issuecomment-770150526 | https://api.github.com/repos/dogsheep/github-to-sqlite/issues/51 | MDEyOklzc3VlQ29tbWVudDc3MDE1MDUyNg== | daniel-butler 22578954 | 2021-01-30T03:44:19Z | 2021-01-30T03:47:24Z | CONTRIBUTOR | I don't have much experience with github's rate limiting. In my day job we use the [tenacity library](https://github.com/jd/tenacity) to handle http errors we get. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | github-to-sqlite should handle rate limits better 703246031 | |
770112248 | https://github.com/dogsheep/github-to-sqlite/issues/60#issuecomment-770112248 | https://api.github.com/repos/dogsheep/github-to-sqlite/issues/60 | MDEyOklzc3VlQ29tbWVudDc3MDExMjI0OA== | daniel-butler 22578954 | 2021-01-30T00:01:03Z | 2021-01-30T01:14:42Z | CONTRIBUTOR | Yes that would be cool! I wouldn't mind helping. Is this the meat of it? https://github.com/dogsheep/twitter-to-sqlite/blob/21fc1cad6dd6348c67acff90a785b458d3a81275/twitter_to_sqlite/utils.py#L512 It looks like the cli option is added with this decorator : https://github.com/dogsheep/twitter-to-sqlite/blob/21fc1cad6dd6348c67acff90a785b458d3a81275/twitter_to_sqlite/cli.py#L14 I looked a bit at utils.py in the GitHub repository. I was surprised at the amount of manual mapping of the API response you had to do to get this to work. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Use Data from SQLite in other commands 797097140 | |
770069864 | https://github.com/dogsheep/github-to-sqlite/issues/60#issuecomment-770069864 | https://api.github.com/repos/dogsheep/github-to-sqlite/issues/60 | MDEyOklzc3VlQ29tbWVudDc3MDA2OTg2NA== | daniel-butler 22578954 | 2021-01-29T21:52:05Z | 2021-02-12T18:29:43Z | CONTRIBUTOR | For the purposes below I am assuming the organization I would get all the repositories and their related commits from is called `gh-organization`. The github's owner id of gh-orgnization is `123456789`. ```bash github-to-sqlite repos github.db gh-organization ``` I'm on a windows computer running git bash to be able to use the `|` command. This works for me ```bash sqlite3 github.db "SELECT full_name FROM repos WHERE owner = '123456789';" | tr '\n\r' ' ' | xargs | { read repos; github-to-sqlite commits github.db $repos; } ``` On a pure linux system I think this would work because the new line character is normally `\n` ```bash sqlite3 github.db "SELECT full_name FROM repos WHERE owner = '123456789';" | tr '\n' ' ' | xargs | { read repos; github-to-sqlite commits github.db $repos; }` ``` As expected I ran into rate limit issues #51 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Use Data from SQLite in other commands 797097140 | |
1641082395 | https://github.com/simonw/datasette/issues/2104#issuecomment-1641082395 | https://api.github.com/repos/simonw/datasette/issues/2104 | IC_kwDOBm6k_c5h0O4b | asg017 15178711 | 2023-07-18T22:41:37Z | 2023-07-18T22:41:37Z | CONTRIBUTOR | For filtering virtual table's "shadow tables" (ex the FTS5 _content and most the spatialite tables), you can use `pragma_table_list` (first appeared in SQLite 3.37 (2021-11-27), which has a `type` column that calls out `type="shadow"` tables https://www.sqlite.org/pragma.html#pragma_table_list | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Tables starting with an underscore should be treated as hidden 1808215339 | |
1616853644 | https://github.com/simonw/datasette/issues/2087#issuecomment-1616853644 | https://api.github.com/repos/simonw/datasette/issues/2087 | IC_kwDOBm6k_c5gXzqM | asg017 15178711 | 2023-07-02T22:00:48Z | 2023-07-02T22:00:48Z | CONTRIBUTOR | I just saw in the docs that Dasette auto-detects `settings.json`: > settings.json - settings that would normally be passed using --setting - here they should be stored as a JSON object of key/value pairs > [*Source*](https://docs.datasette.io/en/stable/settings.html#:~:text=settings.json%20%2D%20settings%20that%20would%20normally%20be%20passed%20using%20%2D%2Dsetting%20%2D%20here%20they%20should%20be%20stored%20as%20a%20JSON%20object%20of%20key/value%20pairs) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | `--settings settings.json` option 1765870617 | |
1616286848 | https://github.com/simonw/datasette/issues/2093#issuecomment-1616286848 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gVpSA | asg017 15178711 | 2023-07-02T02:17:46Z | 2023-07-02T02:17:46Z | CONTRIBUTOR | Storing metadata in the database won't be required. I imagine there'll be many different ways to store metadata, including any possible `datasette_metadata` or sqlite-docs, or the older metadata.json way. The next question will be how precedence should work - i'd imagine metadata.json > plugins > datasette_metadata > sqlite-docs | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
1616095810 | https://github.com/simonw/datasette/pull/2052#issuecomment-1616095810 | https://api.github.com/repos/simonw/datasette/issues/2052 | IC_kwDOBm6k_c5gU6pC | asg017 15178711 | 2023-07-01T20:31:31Z | 2023-07-01T20:31:31Z | CONTRIBUTOR | > Just curious, is there a query that can be used to compile this programmatically, or did you identify these through memory? I just did a github search for `user:simonw "def extra_js_urls("` ! Though I'm sure other plugins made by people other than Simon also exist out there https://github.com/search?q=user%3Asimonw+%22def+extra_js_urls%28%22&type=code | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | feat: Javascript Plugin API (Custom panels, column menu items with JS actions) 1651082214 | |
1613896210 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613896210 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMhoS | asg017 15178711 | 2023-06-29T22:53:33Z | 2023-06-29T22:53:33Z | CONTRIBUTOR | Maybe we can have a separate issue for revamping `metadata.json`? A `datasette_metadata` table or the `sqlite-docs` extension seem like two reasonable additions that we can work through. Storing metadata inside a SQLite database makes sense, but I don't think storing `datasette.*` style config (ex ports, settings, etc.) inside a SQLite DB makes sense, since it's very environment-dependent | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
1613895188 | https://github.com/simonw/datasette/issues/2093#issuecomment-1613895188 | https://api.github.com/repos/simonw/datasette/issues/2093 | IC_kwDOBm6k_c5gMhYU | asg017 15178711 | 2023-06-29T22:51:53Z | 2023-06-29T22:51:53Z | CONTRIBUTOR | I agree with not liking `metadata.json` stuff in a `datasette.*` config file. Editing description of a table/column in a file like `datasette.*` seems odd to me. Though since plugin configuration currently lives in `metadata.json`, I think it should be removed from there and placed in `datasette.*`, at least for top-level config like `datasette-auth-github`'s config. Keeping `metadata.json` strictly for documentation/licensing/column units makes sense to me, but anything plugin related should be in some config file, like `datasette.*`. And ya, supporting both `datasette.*` and CLI flags makes a lot of sense to me. Any `--setting` flag should override anything in `datasette.*` for easier debugging, with possibly a warning message so people don't get confused. Same with `--port` and a port defined in `datasette.*` | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Proposal: Combine settings, metadata, static, etc. into a single `datasette.toml` File 1781530343 | |
1613778296 | https://github.com/simonw/datasette/pull/2052#issuecomment-1613778296 | https://api.github.com/repos/simonw/datasette/issues/2052 | IC_kwDOBm6k_c5gME14 | asg017 15178711 | 2023-06-29T20:36:09Z | 2023-06-29T20:36:09Z | CONTRIBUTOR | Ok @hydrosquall a couple things before this PR should be good to go: - Can we move `datasette/static/table-example-plugins.js` into `demos/plugins/static`? - For `datasetteManager.VERSION`, can we fill that in or just comment it out for now? Not sure how difficult it'll be to inject it server-side. I imagine we could also have a small build process with esbuild/rollup that just injects a version string into `manager.js` directly, so we don't have to worry about server-rendering (but that can be a future PR) In terms of how to integrate this into Datasette, a few options I can see working: - Push this as-is and figure it out before the next release - Hide this feature behind a settings flag (`--setting unstable-js-plugins on`) and use that setting to hide/show `<script src="{{ urls.static('datasette-manager.js') }}" defer></script>` in `base.html` I'll let @simonw decide which one to work with. I kindof like the idea of having an "unstable" opt-in process to enable JS plugins, to give us time to try it out with a wide variety of plugins until we feel its ready. I'm also curious to see how "plugins for a plugin' would work, like #1542. For example, if the leaflet plugin showed default markers, but also included its own hook for other plugins to add more markers/styling. I'm imagine that the individual plugin would re-create their own plugin system compared to this, since handling "plugins of plugins" at the top with Datasette seems really convoluted. Also for posterity, here's a list of Simon's Datasette plugins that use "extra_js_urls()", which probably means they can be ported/re-written to use this new plugin system: - [`datasette-vega`](https://github.com/simonw/datasette-vega/blob/00de059ab1ef77394ba9f9547abfacf966c479c4/datasette_vega/__init__.py#L25) - [`datasette-cluster-map`](https://github.com/simonw/datasette-cluster-map/blob/795d25ad9ff6cba0307191f44fecc8f8070bef5c/datasette_cluster_map/__init__.py#L14) - [`datasette-leaflet-geojson`](https://github.com/simonw/datasette-leaflet… | {"total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 1} | feat: Javascript Plugin API (Custom panels, column menu items with JS actions) 1651082214 | |
1606352600 | https://github.com/simonw/datasette/pull/2052#issuecomment-1606352600 | https://api.github.com/repos/simonw/datasette/issues/2052 | IC_kwDOBm6k_c5fvv7Y | asg017 15178711 | 2023-06-26T00:17:04Z | 2023-06-26T00:17:04Z | CONTRIBUTOR | :wave: would love to see this get merged soon! I want to make a javascript plugin on top of the code-mirror editor to make a few things nicer (function auto-complete, table/column descriptions, etc.), and this would help out a bunch | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | feat: Javascript Plugin API (Custom panels, column menu items with JS actions) 1651082214 | |
1321460293 | https://github.com/simonw/datasette/issues/1884#issuecomment-1321460293 | https://api.github.com/repos/simonw/datasette/issues/1884 | IC_kwDOBm6k_c5Ow-JF | asg017 15178711 | 2022-11-21T04:40:55Z | 2022-11-21T04:40:55Z | CONTRIBUTOR | Counting any virtual tables can be pretty tricky. On one hand, counting a [CSV virtual table](https://www.sqlite.org/csv.html) would return the number of rows in the CSV, which is helpful (but can be I/O intensive). Counting a [FTS5 virtual table](https://www.sqlite.org/fts5.html) would return the number of entries in the FTS index, which is kindof helpful, but can be misleading in some cases. On the other hand, arbitrarily running `COUNT(*)` on some virtual tables can be incredibly expensive. SQLite offers new shortcuts/pushdowns on `COUNT(*)` queries for virtual tables, and instead calls the underlying vtab implementation and iterates through all rows in the table without discretion. For example, a virtual table that's backed by a Postgres table would call `select * from pg_table`, which would use up a lot of network and CPU calls. Or a virtual table backed by a [google sheet](https://github.com/0x6b/libgsqlite) would make network/API requests to get all the rows from the sheet just to make a count. The [`pragma_table_list`](https://www.sqlite.org/pragma.html#pragma_table_list) pragma tells you when a table is a regular table or virtual (in the `type` column), but was only added in version 3.37.0 (2021-11-27). Personally, I wouldnt try to `COUNT(*)` virtual tables - it depends on how the virtual table is implemented, it requires that the connection has the proper extensions loaded, and it may accientally cause perf issues for new-age extensions. A few extensions that I'm writing have virtual tables that wouldn't benefit much from `COUNT(*)`, and the fact that SQLite iterates through all rows in a table to count just makes things worse. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Exclude virtual tables from datasette inspect 1439009231 | |
1292519956 | https://github.com/simonw/datasette/issues/1851#issuecomment-1292519956 | https://api.github.com/repos/simonw/datasette/issues/1851 | IC_kwDOBm6k_c5NCkoU | asg017 15178711 | 2022-10-26T19:20:33Z | 2022-10-26T19:20:33Z | CONTRIBUTOR | > This could use a new plugin hook, too. I don't want to complicate your life too much, but for things like GIS, I'd want a way to turn regular JSON into SpatiaLite geometries or combine X/Y coordinates into point geometries and such. Happy to help however I can. @eyeseast Maybe you could do this with triggers? Like you can insert JSON-friendly data into a "raw" table, and create a trigger that transforms that inserted data into the proper table Here's an example: ```sql -- meant to be updated from a Datasette insert create table points_raw(longitude int, latitude int); -- the target table with proper spatliate geometries create table points(point geometry); CREATE TRIGGER insert_points_raw INSERT ON points_raw BEGIN insert into points(point) values (makepoint(new.longitude, new.latitude)) END; ``` You could then POST a new row to `points_raw` like this: ``` POST /db/points_raw Authorization: Bearer xxx Content-Type: application/json { "row": { "longitude": 27.64356, "latitude": -47.29384 } } ``` Then SQLite with run the trigger and insert a new row in `points` with the correct geometry point. Downside is you'd have duplicated data with `points_raw`, but maybe it could be a `TEMP` table (or have a cron that deletes all rows from that table every so often?) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | API to insert a single record into an existing table 1421544654 | |
1223347322 | https://github.com/simonw/datasette/pull/1789#issuecomment-1223347322 | https://api.github.com/repos/simonw/datasette/issues/1789 | IC_kwDOBm6k_c5I6sx6 | asg017 15178711 | 2022-08-23T00:03:20Z | 2022-08-23T00:03:20Z | CONTRIBUTOR | @simonw to build the extension on ubuntu, you can run: ``` apt-get update && apt-get install libsqlite3-dev gcc gcc ext.c -fPIC -shared -o ext.so ``` I'm not the best with Actions, but if you set the cache key to `ext.c`, run those two commands to download dependencies + compile to `ext.so`, then the unit test should pick it up and run it correctly. Let me know if you want me to update the PR with that added | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add new entrypoint option to `--load-extension` 1344823170 | |
1221576460 | https://github.com/simonw/datasette/pull/1789#issuecomment-1221576460 | https://api.github.com/repos/simonw/datasette/issues/1789 | IC_kwDOBm6k_c5Iz8cM | asg017 15178711 | 2022-08-21T16:16:42Z | 2022-08-21T16:16:42Z | CONTRIBUTOR | Rebased, Read the docs failure should now now fixed Re docs - ya that's a pretty ambitious page, I'm still not 100% sure what the best practices are/should be... Would be happy to make that page in a future PR | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add new entrypoint option to `--load-extension` 1344823170 | |
975955589 | https://github.com/simonw/datasette/issues/1528#issuecomment-975955589 | https://api.github.com/repos/simonw/datasette/issues/1528 | IC_kwDOBm6k_c46K-aF | asg017 15178711 | 2021-11-22T22:00:30Z | 2021-11-22T22:00:30Z | CONTRIBUTOR | Oh, another thing to consider: I believe this would be the first `"_file"` key in datasette's metadata, compared to other `"_url"` keys like `"license_url"` or `"about_url"`. Not too sure what considerations to include with this (ex should missing files cause Datasette to stop before starting, should build scripts bundle these sql files somewhere during `datasette package`, etc.) | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Add new `"sql_file"` key to Canned Queries in metadata? 1060631257 | |
590022164 | https://github.com/simonw/datasette/pull/666#issuecomment-590022164 | https://api.github.com/repos/simonw/datasette/issues/666 | MDEyOklzc3VlQ29tbWVudDU5MDAyMjE2NA== | kevindkeogh 13896256 | 2020-02-23T03:26:00Z | 2020-02-23T03:26:00Z | CONTRIBUTOR | It was very helpful for me, using it for a 15M row table. Added a test, happy to amend though! | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Use inspect-file, if possible, for total row count 562085508 | |
499923145 | https://github.com/simonw/datasette/issues/394#issuecomment-499923145 | https://api.github.com/repos/simonw/datasette/issues/394 | MDEyOklzc3VlQ29tbWVudDQ5OTkyMzE0NQ== | kevindkeogh 13896256 | 2019-06-07T15:10:57Z | 2019-06-07T15:11:07Z | CONTRIBUTOR | Putting this here in case anyone else encounters the same issue with nginx, I was able to resolve it by passing the header in the nginx proxy config (i.e., `proxy_set_header Host $host`). | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | base_url configuration setting 396212021 | |
499320973 | https://github.com/simonw/datasette/issues/394#issuecomment-499320973 | https://api.github.com/repos/simonw/datasette/issues/394 | MDEyOklzc3VlQ29tbWVudDQ5OTMyMDk3Mw== | kevindkeogh 13896256 | 2019-06-06T02:07:59Z | 2019-06-06T02:07:59Z | CONTRIBUTOR | Hey was this ever merged? Trying to run this behind nginx, and encountering this issue. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | base_url configuration setting 396212021 | |
850077261 | https://github.com/simonw/datasette/pull/1348#issuecomment-850077261 | https://api.github.com/repos/simonw/datasette/issues/1348 | MDEyOklzc3VlQ29tbWVudDg1MDA3NzI2MQ== | blairdrummond 10801138 | 2021-05-28T03:05:38Z | 2021-05-28T03:05:38Z | CONTRIBUTOR | Note, the CVEs are probably resolvable with this https://github.com/simonw/datasette/pull/1296 . My experience is that Ubuntu seems to manage these better? Though that is surprising :/ | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | DRAFT: add test and scan for docker images 904598267 | |
837166862 | https://github.com/simonw/datasette/issues/1280#issuecomment-837166862 | https://api.github.com/repos/simonw/datasette/issues/1280 | MDEyOklzc3VlQ29tbWVudDgzNzE2Njg2Mg== | blairdrummond 10801138 | 2021-05-10T19:07:46Z | 2021-05-10T19:07:46Z | CONTRIBUTOR | Do you have a list of sqlite versions you want to test against? One cool thing I saw recently (that we started using) was using `import docker` within python, and then writing pytest functions which executed against the container [setup](https://github.com/StatCan/kubeflow-containers/blob/3c7dcfb5e7188982fb8ebcded82e84292720f720/conftest.py#L85) [example](https://github.com/StatCan/kubeflow-containers/blob/master/tests/jupyterlab-cpu/test_julia.py#L8-L18) The inspiration for this came from the [jupyter docker-stacks](https://github.com/jupyter/docker-stacks/blob/09fb66007615ea68d9bce8f8e1a2cf9402f1e432/test/test_packages.py#L107) So off the top of my head, could look at building the container with different sqlite versions as a build-arg, then run tests against the containers. Just brainstorming though | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to run CI against multiple SQLite versions 842862708 | |
835491318 | https://github.com/simonw/datasette/pull/1296#issuecomment-835491318 | https://api.github.com/repos/simonw/datasette/issues/1296 | MDEyOklzc3VlQ29tbWVudDgzNTQ5MTMxOA== | blairdrummond 10801138 | 2021-05-08T19:59:01Z | 2021-05-08T19:59:01Z | CONTRIBUTOR | I have also found that ubuntu has fewer vulnerabilities than the buster based images. ``` ➜ ~ docker pull python:3-buster ➜ ~ trivy image python:3-buster | head 2021-04-28T17:14:29.313-0400 INFO Detecting Debian vulnerabilities... 2021-04-28T17:14:29.393-0400 INFO Trivy skips scanning programming language libraries because no supported file was detected python:3-buster (debian 10.9) ============================= Total: 1621 (UNKNOWN: 13, LOW: 1106, MEDIUM: 343, HIGH: 145, CRITICAL: 14) +------------------------------+---------------------+----------+------------------------------+---------------+--------------------------------------------------------------+ | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE | +------------------------------+---------------------+----------+------------------------------+---------------+--------------------------------------------------------------+ ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Dockerfile: use Ubuntu 20.10 as base 855446829 | |
489163939 | https://github.com/simonw/datasette/pull/434#issuecomment-489163939 | https://api.github.com/repos/simonw/datasette/issues/434 | MDEyOklzc3VlQ29tbWVudDQ4OTE2MzkzOQ== | rprimet 10352819 | 2019-05-03T16:49:45Z | 2019-05-03T16:50:03Z | CONTRIBUTOR | > The second time I ran the command I got an error: > > ERROR: (gcloud.beta.run.deploy) Deployment endpoint was not found. Perhaps the > provided region was invalid. Set the `run/region` property to a valid region and > retry. Ex: `gcloud config set run/region us-central1` > Yes, I was able to reproduce this; I used to get prompted for a run region interactively by the `gcloud` tool before, but maybe this is changing? (the [documentation](https://cloud.google.com/run/docs/deploying) now assumes `run/region` is set). Not sure which course of action is best: making `datasette` ensure that `run/region` is set beforehand or wait a bit until the gcloud CLI stabilizes? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | "datasette publish cloudrun" command to publish to Google Cloud Run 434321685 | |
1592110694 | https://github.com/simonw/sqlite-utils/issues/529#issuecomment-1592110694 | https://api.github.com/repos/simonw/sqlite-utils/issues/529 | IC_kwDOCGYnMM5e5a5m | chapmanjacobd 7908073 | 2023-06-14T23:11:47Z | 2023-06-14T23:12:12Z | CONTRIBUTOR | sorry i was wrong. `sqlite-utils --raw-lines` works correctly ``` sqlite-utils --raw-lines :memory: "SELECT * FROM (VALUES ('test'), ('line2'))" | cat -A test$ line2$ sqlite-utils --csv --no-headers :memory: "SELECT * FROM (VALUES ('test'), ('line2'))" | cat -A test$ line2$ ``` I think this was fixed somewhat recently | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Microsoft line endings 1581090327 | |
1592052320 | https://github.com/simonw/sqlite-utils/issues/535#issuecomment-1592052320 | https://api.github.com/repos/simonw/sqlite-utils/issues/535 | IC_kwDOCGYnMM5e5Mpg | chapmanjacobd 7908073 | 2023-06-14T22:05:28Z | 2023-06-14T22:05:28Z | CONTRIBUTOR | piping to `jq` is good enough usually | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | rows: --transpose or psql extended view-like functionality 1655860104 | |
1592047502 | https://github.com/simonw/sqlite-utils/issues/555#issuecomment-1592047502 | https://api.github.com/repos/simonw/sqlite-utils/issues/555 | IC_kwDOCGYnMM5e5LeO | chapmanjacobd 7908073 | 2023-06-14T22:00:10Z | 2023-06-14T22:01:57Z | CONTRIBUTOR | You may want to try doing a performance comparison between this and just selecting all the ids with few constraints and then doing the filtering within python. That might seem like a lazy-programmer, inefficient way but queries with large resultsets are a different profile than what databases like SQLITE are designed for. That is not to say that SQLITE is slow or that python is always faster but when you start reading >20% of an index there is an equilibrium that is reached. Especially when adding in writing extra temp tables and stuff to memory/disk. And especially given the `NOT IN` style of query... You may also try chunking like this: ```py def chunks(lst, n) -> Generator: for i in range(0, len(lst), n): yield lst[i : i + n] SQLITE_PARAM_LIMIT = 32765 data = [] chunked = chunks(video_ids, consts.SQLITE_PARAM_LIMIT) for ids in chunked: data.expand( list( db.query( f"""SELECT * from videos WHERE id in (""" + ",".join(["?"] * len(ids)) + ")", (*ids,), ) ) ) ``` but that actually won't work with your `NOT IN` requirements. You need to query the full resultset to check any row. Since you are doing stuff with files/videos in SQLITE you might be interested in my side project: https://github.com/chapmanjacobd/library | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Filter table by a large bunch of ids 1733198948 | |
1590531892 | https://github.com/simonw/sqlite-utils/issues/557#issuecomment-1590531892 | https://api.github.com/repos/simonw/sqlite-utils/issues/557 | IC_kwDOCGYnMM5ezZc0 | chapmanjacobd 7908073 | 2023-06-14T06:09:21Z | 2023-06-14T06:09:21Z | CONTRIBUTOR | I put together a [simple script](https://github.com/chapmanjacobd/library/blob/42129c5ebe15f9d74653c0f5ca4ed0c991d383e0/xklb/scripts/dedupe_db.py) to upsert and remove duplicate rows based on business keys. If anyone has similar problems with above this might help ``` CREATE TABLE my_table ( id INTEGER PRIMARY KEY, column1 TEXT, column2 TEXT, column3 TEXT ); INSERT INTO my_table (column1, column2, column3) VALUES ('Value 1', 'Duplicate 1', 'Duplicate A'), ('Value 2', 'Duplicate 2', 'Duplicate B'), ('Value 3', 'Duplicate 2', 'Duplicate C'), ('Value 4', 'Duplicate 3', 'Duplicate D'), ('Value 5', 'Duplicate 3', 'Duplicate E'), ('Value 6', 'Duplicate 3', 'Duplicate F'); ``` ``` library dedupe-db test.db my_table --bk column2 ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Aliased ROWID option for tables created from alter=True commands 1740150327 | |
1577355134 | https://github.com/simonw/sqlite-utils/issues/557#issuecomment-1577355134 | https://api.github.com/repos/simonw/sqlite-utils/issues/557 | IC_kwDOCGYnMM5eBId- | chapmanjacobd 7908073 | 2023-06-05T19:26:26Z | 2023-06-05T19:26:26Z | CONTRIBUTOR | this isn't really actionable... I'm just being a whiny baby. I have tasted the milk of being able to use `upsert_all`, `insert_all`, etc without having to write DDL to create tables. The meat of the issue is that SQLITE doesn't make rowid stable between vacuums so it is not possible to take shortcuts | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Aliased ROWID option for tables created from alter=True commands 1740150327 | |
1318777114 | https://github.com/simonw/sqlite-utils/issues/510#issuecomment-1318777114 | https://api.github.com/repos/simonw/sqlite-utils/issues/510 | IC_kwDOCGYnMM5OmvEa | chapmanjacobd 7908073 | 2022-11-17T15:09:47Z | 2022-11-17T15:09:47Z | CONTRIBUTOR | why close? is the only problem that the _config table that incorrectly says 4 for fts5? if so, that's still something that should be fixed | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Cannot enable FTS5 despite it being available 1434911255 | |
1304320521 | https://github.com/simonw/sqlite-utils/issues/511#issuecomment-1304320521 | https://api.github.com/repos/simonw/sqlite-utils/issues/511 | IC_kwDOCGYnMM5NvloJ | chapmanjacobd 7908073 | 2022-11-04T22:54:09Z | 2022-11-04T22:59:54Z | CONTRIBUTOR | I ran `PRAGMA integrity_check` and it returned `ok`. but then I tried restoring from a backup and I didn't get this `IntegrityError: constraint failed` error. So I think it was just something wrong with my database. If it happens again I will first try to reindex and see if that fixes the issue | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | [insert_all, upsert_all] IntegrityError: constraint failed 1436539554 | |
1304078945 | https://github.com/simonw/sqlite-utils/issues/511#issuecomment-1304078945 | https://api.github.com/repos/simonw/sqlite-utils/issues/511 | IC_kwDOCGYnMM5Nuqph | chapmanjacobd 7908073 | 2022-11-04T19:38:36Z | 2022-11-04T20:13:17Z | CONTRIBUTOR | Even more bizarre, the source db only has one record and the target table has no conflicting record: ``` 875 0.3s lb:/ (main|✚2) [0|0]🌺 sqlite-utils tube_71.db 'select * from media where path = "https://archive.org/details/088ghostofachanceroygetssackedrevengeofthelivinglunchdvdripxvidphz"' | jq [ { "size": null, "time_created": null, "play_count": 1, "language": null, "view_count": null, "width": null, "height": null, "fps": null, "average_rating": null, "live_status": null, "age_limit": null, "uploader": null, "time_played": 0, "path": "https://archive.org/details/088ghostofachanceroygetssackedrevengeofthelivinglunchdvdripxvidphz", "id": "088ghostofachanceroygetssackedrevengeofthelivinglunchdvdripxvidphz/074 - Home Away from Home, Rainy Day Robot, Odie the Amazing DVDRip XviD [PhZ].mkv", "ie_key": "ArchiveOrg", "playlist_path": "https://archive.org/details/088ghostofachanceroygetssackedrevengeofthelivinglunchdvdripxvidphz", "duration": 1424.05, "tags": null, "title": "074 - Home Away from Home, Rainy Day Robot, Odie the Amazing DVDRip XviD [PhZ].mkv" } ] 875 0.3s lb:/ (main|✚2) [0|0]🥧 sqlite-utils video.db 'select * from media where path = "https://archive.org/details/088ghostofachanceroygetssackedrevengeofthelivinglunchdvdripxvidphz"' | jq [] ``` I've been able to use this code successfully several times before so not sure what's causing the issue. I guess the way that I'm handling multiple databases is an issue, though it hasn't ever inserted into the source db, not sure what's different. The only reasonable explanation is that it is trying to insert into the source db from the source db for some reason? Or maybe sqlite3 is checking the source db for primary key violation because the table name is the same | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | [insert_all, upsert_all] IntegrityError: constraint failed 1436539554 | |
1303660293 | https://github.com/simonw/sqlite-utils/issues/50#issuecomment-1303660293 | https://api.github.com/repos/simonw/sqlite-utils/issues/50 | IC_kwDOCGYnMM5NtEcF | chapmanjacobd 7908073 | 2022-11-04T14:38:36Z | 2022-11-04T14:38:36Z | CONTRIBUTOR | where did you see the limit as 999? I believe the limit has been 32766 for quite some time. If you could detect which one this could speed up batch insert of some types of data significantly | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | "Too many SQL variables" on large inserts 473083260 | |
1297859539 | https://github.com/simonw/sqlite-utils/issues/507#issuecomment-1297859539 | https://api.github.com/repos/simonw/sqlite-utils/issues/507 | IC_kwDOCGYnMM5NW8PT | chapmanjacobd 7908073 | 2022-11-01T00:40:16Z | 2022-11-01T00:40:16Z | CONTRIBUTOR | Ideally people could fix their data if they run into this issue. If you are using filenames try [convmv](https://linux.die.net/man/1/convmv) ``` convmv --preserve-mtimes -f utf8 -t utf8 --notest -i -r . ``` maybe this script will also help: ```py import argparse, shutil from pathlib import Path import ftfy from xklb import utils from xklb.utils import log def parse_args() -> argparse.Namespace: parser = argparse.ArgumentParser() parser.add_argument("paths", nargs='*') parser.add_argument("--verbose", "-v", action="count", default=0) args = parser.parse_args() log.info(utils.dict_filter_bool(args.__dict__)) return args def rename_invalid_paths() -> None: args = parse_args() for path in args.paths: log.info(path) for p in sorted([str(p) for p in Path(path).rglob("*")], key=len): fixed = ftfy.fix_text(p, uncurl_quotes=False).replace("\r\n", "\n").replace("\r", "\n").replace("\n", "") if p != fixed: try: shutil.move(p, fixed) except FileNotFoundError: log.warning("FileNotFound. %s", p) else: log.info(fixed) if __name__ == "__main__": rename_invalid_paths() ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | conn.execute: UnicodeEncodeError: 'utf-8' codec can't encode character 1430325103 | |
1297788531 | https://github.com/simonw/sqlite-utils/pull/508#issuecomment-1297788531 | https://api.github.com/repos/simonw/sqlite-utils/issues/508 | IC_kwDOCGYnMM5NWq5z | chapmanjacobd 7908073 | 2022-10-31T22:54:33Z | 2022-11-17T15:11:16Z | CONTRIBUTOR | Maybe this is actually a problem in the python sqlite bindings. Given [SQLITE's stance on this](https://www.sqlite.org/invalidutf.html) they should probably use `encode('utf-8', 'surrogatepass')`. As far as I understand the error here won't actually be resolved by this PR as-is. We would need to modify the data with `surrogateescape`... :/ or modify the sqlite3 module to use `surrogatepass` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Allow surrogates in parameters 1430563092 | |
1292401308 | https://github.com/simonw/sqlite-utils/pull/499#issuecomment-1292401308 | https://api.github.com/repos/simonw/sqlite-utils/issues/499 | IC_kwDOCGYnMM5NCHqc | chapmanjacobd 7908073 | 2022-10-26T17:54:26Z | 2022-10-26T17:54:51Z | CONTRIBUTOR | The problem with how it is currently is that the transformed fts table _will_ return incorrect results (unless the table was only 1 row or something), even if create_triggers was enabled previously. Maybe the simplest solution is to disable fts on a transformed table rather than try to recreate it? Thoughts? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | feat: recreate fts triggers after table transform 1405196044 | |
1274153135 | https://github.com/simonw/sqlite-utils/pull/498#issuecomment-1274153135 | https://api.github.com/repos/simonw/sqlite-utils/issues/498 | IC_kwDOCGYnMM5L8giv | chapmanjacobd 7908073 | 2022-10-11T06:34:31Z | 2022-10-11T06:34:31Z | CONTRIBUTOR | nevermind it was because I was running `db[table].transform`. The fts tables would still be there but the triggers would be dropped | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | fix: enable-fts permanently save triggers 1404013495 | |
1264223554 | https://github.com/simonw/sqlite-utils/issues/409#issuecomment-1264223554 | https://api.github.com/repos/simonw/sqlite-utils/issues/409 | IC_kwDOCGYnMM5LWoVC | chapmanjacobd 7908073 | 2022-10-01T03:42:50Z | 2022-10-01T03:42:50Z | CONTRIBUTOR | oh weird. it inserts into db2 | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | `with db:` for transactions 1149661489 | |
1264223363 | https://github.com/simonw/sqlite-utils/issues/409#issuecomment-1264223363 | https://api.github.com/repos/simonw/sqlite-utils/issues/409 | IC_kwDOCGYnMM5LWoSD | chapmanjacobd 7908073 | 2022-10-01T03:41:45Z | 2022-10-01T03:41:45Z | CONTRIBUTOR | ``` pytest xklb/check.py --pdb xklb/check.py:11: in test_transaction assert list(db2["t"].rows) == [] E AssertionError: assert [{'foo': 1}] == [] E + where [{'foo': 1}] = list(<generator object Queryable.rows_where at 0x7f2d84d1f0d0>) E + where <generator object Queryable.rows_where at 0x7f2d84d1f0d0> = <Table t (foo)>.rows >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entering PDB >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PDB post_mortem (IO-capturing turned off) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > /home/xk/github/xk/lb/xklb/check.py(11)test_transaction() 9 with db1.conn: 10 db1["t"].insert({"foo": 1}) ---> 11 assert list(db2["t"].rows) == [] 12 assert list(db2["t"].rows) == [{"foo": 1}] ``` It fails because it is already inserted. btw if you put these two lines in you pyproject.toml you can get `ipdb` in pytest ``` [tool.pytest.ini_options] addopts = "--pdbcls=IPython.terminal.debugger:TerminalPdb --ignore=tests/data --capture=tee-sys --log-cli-level=ERROR" ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | `with db:` for transactions 1149661489 | |
1264219650 | https://github.com/simonw/sqlite-utils/issues/493#issuecomment-1264219650 | https://api.github.com/repos/simonw/sqlite-utils/issues/493 | IC_kwDOCGYnMM5LWnYC | chapmanjacobd 7908073 | 2022-10-01T03:22:50Z | 2022-10-01T03:23:58Z | CONTRIBUTOR | this is likely what you are looking for: https://stackoverflow.com/a/51076749/697964 but yeah I would say just disable smart quotes | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Tiny typographical error in install/uninstall docs 1386562662 | |
1264218914 | https://github.com/simonw/sqlite-utils/issues/491#issuecomment-1264218914 | https://api.github.com/repos/simonw/sqlite-utils/issues/491 | IC_kwDOCGYnMM5LWnMi | chapmanjacobd 7908073 | 2022-10-01T03:18:36Z | 2023-06-14T22:14:24Z | CONTRIBUTOR | > some good concrete use-cases in mind I actually found myself wanting something like this the past couple days. The use-case was databases with slightly different schema but same table names. here is a full script: ``` import argparse from pathlib import Path from sqlite_utils import Database def connect(args, conn=None, **kwargs) -> Database: db = Database(conn or args.database, **kwargs) with db.conn: db.conn.execute("PRAGMA main.cache_size = 8000") return db def parse_args() -> argparse.Namespace: parser = argparse.ArgumentParser() parser.add_argument("database") parser.add_argument("dbs_folder") parser.add_argument("--db", "-db", help=argparse.SUPPRESS) parser.add_argument("--verbose", "-v", action="count", default=0) args = parser.parse_args() if args.db: args.database = args.db Path(args.database).touch() args.db = connect(args) return args def merge_db(args, source_db): source_db = str(Path(source_db).resolve()) s_db = connect(argparse.Namespace(database=source_db, verbose = args.verbose)) for table in s_db.table_names(): data = s_db[table].rows args.db[table].insert_all(data, alter=True, replace=True) args.db.conn.commit() def merge_directory(): args = parse_args() source_dbs = list(Path(args.dbs_folder).glob('*.db')) for s_db in source_dbs: merge_db(args, s_db) if __name__ == '__main__': merge_directory() ``` edit: I've made some improvements to this and put it on PyPI: ``` $ pip install xklb $ lb merge-db -h usage: library merge-dbs DEST_DB SOURCE_DB ... [--only-target-columns] [--only-new-rows] [--upsert] [--pk PK ...] [--table TABLE ...] Merge-DBs will insert new rows from source dbs to target db, table by table. If primary key(s) are provided, and there is an existing row with the same PK, the default action is to delete the existing row and insert the new row replacing all exist… | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to merge databases and tables 1383646615 | |
1256858763 | https://github.com/simonw/sqlite-utils/issues/491#issuecomment-1256858763 | https://api.github.com/repos/simonw/sqlite-utils/issues/491 | IC_kwDOCGYnMM5K6iSL | chapmanjacobd 7908073 | 2022-09-24T04:50:59Z | 2022-09-24T04:52:08Z | CONTRIBUTOR | Instead of outputting binary data to stdout the interface might be better like this ``` sqlite-utils merge animals.db cats.db dogs.db ``` similar to `zip`, `ogr2ogr`, etc Actually I think this might already be possible within `ogr2ogr`. I don't believe spatial data is a requirement though it might add an `ogc_id` column or something ``` cp cats.db animals.db ogr2ogr -append animals.db dogs.db ogr2ogr -append animals.db another.db ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Ability to merge databases and tables 1383646615 | |
1252898131 | https://github.com/simonw/sqlite-utils/issues/433#issuecomment-1252898131 | https://api.github.com/repos/simonw/sqlite-utils/issues/433 | IC_kwDOCGYnMM5KrbVT | chapmanjacobd 7908073 | 2022-09-20T20:51:21Z | 2022-09-20T20:56:07Z | CONTRIBUTOR | When I run `reset` it fixes my terminal. I suspect it is related to the progress bar https://linux.die.net/man/1/reset ``` 950 1s /m/d/03_Downloads 🐑 echo $TERM xterm-kitty ▓░▒░ /m/d/03_Downloads 🌏 kitty -v kitty 0.26.2 created by Kovid Goyal $ sqlite-utils insert test.db facility facility-boundary-us-all.csv --csv blah blah blah (no offense) $ <no cursor> $ reset $ <cursor lives again (resurrection [explicit])> ``` | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | CLI eats my cursor 1239034903 | |
1232356302 | https://github.com/simonw/sqlite-utils/pull/480#issuecomment-1232356302 | https://api.github.com/repos/simonw/sqlite-utils/issues/480 | IC_kwDOCGYnMM5JdEPO | chapmanjacobd 7908073 | 2022-08-31T01:51:49Z | 2022-08-31T01:51:49Z | CONTRIBUTOR | Thanks for pointing me to the right place | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | search_sql add include_rank option 1355433619 | |
918621705 | https://github.com/simonw/datasette/issues/1464#issuecomment-918621705 | https://api.github.com/repos/simonw/datasette/issues/1464 | IC_kwDOBm6k_c42wQ4J | bobwhitelock 7476523 | 2021-09-13T22:17:17Z | 2021-09-13T22:17:17Z | CONTRIBUTOR | > haven't had time to get back to this, but idle thought that I'm recording for later investigation: how does the continuous integration handle this installation issue? Is it documented there? Not certain, but I think tests in CI run on Ubuntu and don't appear to install any additional Sqlite-related dependencies, and so my guess is the version of Sqlite installed by default on Ubuntu has the `SQLITE_ENABLE_FTS3_PARENTHESIS` option enabled and so doesn't run into this issue. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | clean checkout & clean environment has test failures 991191951 | |
915343886 | https://github.com/simonw/datasette/issues/1464#issuecomment-915343886 | https://api.github.com/repos/simonw/datasette/issues/1464 | IC_kwDOBm6k_c42jwoO | bobwhitelock 7476523 | 2021-09-08T15:32:06Z | 2021-09-08T15:32:06Z | CONTRIBUTOR | Thanks, that does look similar! > Unfortunately, pysqlite3-binary isn't available for Mac OS X, so I can't quickly check that that fixes it; will do so later. Ah that makes sense, I guess that's why this isn't just always installed already. I wonder if a possible solution to this issue could be doing feature detection on whether this feature is supported by the current Sqlite version, and if not these tests could be disabled locally? But possibly there's a better way to handle this, will see what @simonw thinks | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | clean checkout & clean environment has test failures 991191951 | |
915299013 | https://github.com/simonw/datasette/issues/1464#issuecomment-915299013 | https://api.github.com/repos/simonw/datasette/issues/1464 | IC_kwDOBm6k_c42jlrF | bobwhitelock 7476523 | 2021-09-08T14:40:28Z | 2021-09-08T14:40:28Z | CONTRIBUTOR | What are the full errors you're getting? This *may* be the same issue as described in https://github.com/simonw/datasette/pull/1223 - essentially the test suite (and corresponding Datasette features I assume) are by default implicitly dependent on your Sqlite installation having been compiled with the `SQLITE_ENABLE_FTS3_PARENTHESIS` option. If this is the same issue then I think this can be fixed either by recompiling with that option or (probably more easily) by running `pip install pysqlite3-binary`, which will be used in preference to your system Sqlite installation and has this option enabled. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | clean checkout & clean environment has test failures 991191951 | |
805214307 | https://github.com/simonw/datasette/issues/1274#issuecomment-805214307 | https://api.github.com/repos/simonw/datasette/issues/1274 | MDEyOklzc3VlQ29tbWVudDgwNTIxNDMwNw== | bobwhitelock 7476523 | 2021-03-23T20:12:29Z | 2021-03-23T20:12:29Z | CONTRIBUTOR | One issue I could see with adding first class support for metadata in hjson format is that this would require adding an additional dependency to handle this, for a feature that would be unused by many users. I wonder if this could fit in as a plugin instead; if a hook existed for loading metadata (maybe as part of https://github.com/simonw/datasette/issues/860) the metadata could then come from any source, as specified by plugins, e.g. hjson, toml, XML, a database table etc. Until/unless this exists, a few ideas for how you could add comments: - Using YAML as you suggest. - A common pattern is adding a `"comment"` key for comments to any object in JSON - I don't think including an unnecessary key like this would break anything in Datasette, but not certain. - You could use another tool as a preprocessor for your JSON metadata - e.g. hjson or Jsonnet. You'd write the metadata in that format, and then convert that into JSON to actually use as your final metadata. | {"total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Might there be some way to comment metadata.json? 839008371 | |
802923254 | https://github.com/simonw/datasette/issues/1265#issuecomment-802923254 | https://api.github.com/repos/simonw/datasette/issues/1265 | MDEyOklzc3VlQ29tbWVudDgwMjkyMzI1NA== | bobwhitelock 7476523 | 2021-03-19T15:39:15Z | 2021-03-19T15:39:15Z | CONTRIBUTOR | It doesn't use basic auth, but you can put a whole datasette instance, or parts of this, behind a username/password prompt using https://github.com/simonw/datasette-auth-passwords | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Support for HTTP Basic Authentication 836123030 | |
802095132 | https://github.com/simonw/datasette/issues/1262#issuecomment-802095132 | https://api.github.com/repos/simonw/datasette/issues/1262 | MDEyOklzc3VlQ29tbWVudDgwMjA5NTEzMg== | bobwhitelock 7476523 | 2021-03-18T16:37:45Z | 2021-03-18T16:37:45Z | CONTRIBUTOR | This sounds like a good use case for a plugin, since this will only be useful for a subset of Datasette users. It shouldn't be too difficult to add a button to do this with the available plugin hooks - have you taken a look at https://docs.datasette.io/en/latest/writing_plugins.html? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Plugin hook that could support 'order by random()' for table view 834602299 | |
778439617 | https://github.com/simonw/datasette/issues/1220#issuecomment-778439617 | https://api.github.com/repos/simonw/datasette/issues/1220 | MDEyOklzc3VlQ29tbWVudDc3ODQzOTYxNw== | bobwhitelock 7476523 | 2021-02-12T20:33:27Z | 2021-02-12T20:33:27Z | CONTRIBUTOR | That Docker command will mount your current directory inside the Docker container at `/mnt` - so you shouldn't need to change anything locally, just run ``` docker run -p 8001:8001 -v `pwd`:/mnt \ datasetteproject/datasette \ datasette -p 8001 -h 0.0.0.0 /mnt/fixtures.db ``` and it will use the `fixtures.db` file within your current directory | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Installing datasette via docker: Path 'fixtures.db' does not exist 806743116 | |
777927946 | https://github.com/simonw/datasette/issues/1220#issuecomment-777927946 | https://api.github.com/repos/simonw/datasette/issues/1220 | MDEyOklzc3VlQ29tbWVudDc3NzkyNzk0Ng== | bobwhitelock 7476523 | 2021-02-12T02:29:54Z | 2021-02-12T02:29:54Z | CONTRIBUTOR | According to https://github.com/simonw/datasette/blob/master/docs/installation.rst#using-docker it should be ``` docker run -p 8001:8001 -v `pwd`:/mnt \ datasetteproject/datasette \ datasette -p 8001 -h 0.0.0.0 /mnt/fixtures.db ``` This uses `/mnt/fixtures.db` whereas you're using `fixtures.db` - did you try using this path instead? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Installing datasette via docker: Path 'fixtures.db' does not exist 806743116 | |
777132761 | https://github.com/simonw/datasette/issues/1200#issuecomment-777132761 | https://api.github.com/repos/simonw/datasette/issues/1200 | MDEyOklzc3VlQ29tbWVudDc3NzEzMjc2MQ== | bobwhitelock 7476523 | 2021-02-11T00:29:52Z | 2021-02-11T00:29:52Z | CONTRIBUTOR | I'm probably missing something but what's the use case here - what would this offer over adding `limit 10` to the query? | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | ?_size=10 option for the arbitrary query page would be useful 792890765 | |
750389683 | https://github.com/simonw/datasette/pull/1158#issuecomment-750389683 | https://api.github.com/repos/simonw/datasette/issues/1158 | MDEyOklzc3VlQ29tbWVudDc1MDM4OTY4Mw== | eumiro 6774676 | 2020-12-23T17:02:50Z | 2020-12-23T17:02:50Z | CONTRIBUTOR | The dict/set suggestion comes from `pyupgrade --py36-plus`, but then had to `black` the change. The rest comes from PyCharm's Inspect code function. I reviewed all the suggestions and fixed a thing or two, such as leading/trailing spaces in the docstrings or turned around the chained conditions. Then I tried to convert all `os.path/glob/open` to `Path`, but there were some local test issues, so I'll have to start over in smaller chunks if you want to have that too. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Modernize code to Python 3.6+ 773913793 | |
795112935 | https://github.com/simonw/datasette/pull/1256#issuecomment-795112935 | https://api.github.com/repos/simonw/datasette/issues/1256 | MDEyOklzc3VlQ29tbWVudDc5NTExMjkzNQ== | JBPressac 6371750 | 2021-03-10T08:59:45Z | 2021-03-10T08:59:45Z | CONTRIBUTOR | Sorry, I meant "minor typo" not "minor type". | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Minor type in IP adress 827341657 | |
791509910 | https://github.com/simonw/datasette/issues/766#issuecomment-791509910 | https://api.github.com/repos/simonw/datasette/issues/766 | MDEyOklzc3VlQ29tbWVudDc5MTUwOTkxMA== | JBPressac 6371750 | 2021-03-05T15:57:35Z | 2021-03-05T16:35:21Z | CONTRIBUTOR | Hello, I have the same wildcards search problems with an instance of Datasette. http://crbc-dataset.huma-num.fr/inventaires/fonds_auguste_dupouy_1872_1967?_search=gwerz&_sort=rowid is OK but http://crbc-dataset.huma-num.fr/inventaires/fonds_auguste_dupouy_1872_1967?_search=gwe* is not (FTS is activated on "Reference" "IntituleAnalyse" "NomDuProducteur" "PresentationDuContenu" "Notes"). Notice that a SQL query as below launched directly from SQLite in the server's shell, retrieves results. `select * from fonds_auguste_dupouy_1872_1967_fts where IntituleAnalyse MATCH "gwe*";` Thanks, | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Enable wildcard-searches by default 617323873 | |
743080047 | https://github.com/simonw/datasette/issues/998#issuecomment-743080047 | https://api.github.com/repos/simonw/datasette/issues/998 | MDEyOklzc3VlQ29tbWVudDc0MzA4MDA0Nw== | JBPressac 6371750 | 2020-12-11T09:25:09Z | 2020-12-11T09:25:09Z | CONTRIBUTOR | Hello Simon, I have a similar problem with horizontal scrollbar display with Datasette version 0.51 and superior for a table with more than 30 rows. With Datasette 0.50, the horizontal scrollbar is displayed, if I upgrade Datasette to 0.51 and superior, the horizontal scrollbar disappears. Datasette 0.50: horizontal scrollbar ![2020-12-11 10_23_28-CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US](https://user-images.githubusercontent.com/6371750/101885620-a5f17800-3b9a-11eb-8870-654e7d4372ca.png) Datasette 0.51 and superior: no horizontal scrollbar ![2020-12-11 10_24_55-CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US](https://user-images.githubusercontent.com/6371750/101885782-dfc27e80-3b9a-11eb-9d55-6c9a56227bf2.png) Thanks, | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | Wide tables should scroll horizontally within the page 717699884 |
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]);
author_association 1 ✖