14 rows where user = 222245 sorted by updated_at descending

View and edit SQL

Suggested facets: issue_url, created_at (date), updated_at (date)

user

  • carlmjohnson · 14

author_association

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions issue performed_via_github_app
754210356 https://github.com/simonw/datasette/issues/983#issuecomment-754210356 https://api.github.com/repos/simonw/datasette/issues/983 MDEyOklzc3VlQ29tbWVudDc1NDIxMDM1Ng== carlmjohnson 222245 2021-01-04T20:49:05Z 2021-01-04T20:49:05Z NONE

For reasons I've written about elsewhere, I'm in favor of modules. It has several beneficial effects. One, old browsers just ignore it all together. Two, if you include the same plain script on the page more than once, it will be executed twice, but if you include the same module script on a page twice, it will only execute once. Three, you get a module local namespace, instead of having to use the global window namespace or a function private namespace.

OTOH, if you are going to use an old style script, the code from before isn't ideal, because you wipe out your registry if the script it included more than once. Also you may as well use object methods and splat arguments.

The event based architecture probably makes more sense though. Just make up some event names prefixed with datasette: and listen for them on the root. The only concern with that approach is it can sometimes be tricky to make sure your plugins are run after datasette has run. Maybe

function mycallback(){
  // whatever
}

if (window.datasette) {
  window.datasette.init(mycallback);
} else {
  document.addEventListener('datasette:init', mycallback);
}
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
JavaScript plugin hooks mechanism similar to pluggy 712260429  
712569695 https://github.com/simonw/datasette/issues/782#issuecomment-712569695 https://api.github.com/repos/simonw/datasette/issues/782 MDEyOklzc3VlQ29tbWVudDcxMjU2OTY5NQ== carlmjohnson 222245 2020-10-20T03:45:48Z 2020-10-20T03:46:14Z NONE

I vote against headers. It has a lot of strikes against it: poor discoverability, new developers often don’t know how to use them, makes CORS harder, makes it hard to use eg with JQ, needs ad hoc specification for each bit of metadata, etc.

The only advantage of headers is that you don’t need to do .rows, but that’s actually good as a data validation step anyway—if .rows is missing assume there’s an error and do your error handling path instead of parsing the rest.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Redesign default JSON format in preparation for Datasette 1.0 627794879  
494459264 https://github.com/simonw/datasette/issues/184#issuecomment-494459264 https://api.github.com/repos/simonw/datasette/issues/184 MDEyOklzc3VlQ29tbWVudDQ5NDQ1OTI2NA== carlmjohnson 222245 2019-05-21T16:17:29Z 2019-05-21T16:17:29Z NONE

Reopening this because it still raises 500 for incorrect table capitalization.

Example:

I think because the table name exists but is not in its canonical form, it triggers a dict lookup error.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
500 from missing table name 292011379  
485557574 https://github.com/simonw/datasette/pull/426#issuecomment-485557574 https://api.github.com/repos/simonw/datasette/issues/426 MDEyOklzc3VlQ29tbWVudDQ4NTU1NzU3NA== carlmjohnson 222245 2019-04-22T21:23:22Z 2019-04-22T21:23:22Z NONE

Can you cut a new release with this?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Upgrade to Jinja2==2.10.1 431756352  
439194286 https://github.com/simonw/datasette/issues/227#issuecomment-439194286 https://api.github.com/repos/simonw/datasette/issues/227 MDEyOklzc3VlQ29tbWVudDQzOTE5NDI4Ng== carlmjohnson 222245 2018-11-15T21:20:37Z 2018-11-15T21:20:37Z NONE

I'm diving back into https://salaries.news.baltimoresun.com and what I really want is the ability to inject the request into my context.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
prepare_context() plugin hook 315960272  
412663658 https://github.com/simonw/datasette/issues/185#issuecomment-412663658 https://api.github.com/repos/simonw/datasette/issues/185 MDEyOklzc3VlQ29tbWVudDQxMjY2MzY1OA== carlmjohnson 222245 2018-08-13T21:04:11Z 2018-08-13T21:04:11Z NONE

That seems good to me.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Metadata should be a nested arbitrary KV store 299760684  
381429213 https://github.com/simonw/datasette/issues/189#issuecomment-381429213 https://api.github.com/repos/simonw/datasette/issues/189 MDEyOklzc3VlQ29tbWVudDM4MTQyOTIxMw== carlmjohnson 222245 2018-04-15T18:54:22Z 2018-04-15T18:54:22Z NONE

I think I found a bug. I tried to sort by middle initial in my salaries set, and many middle initials are null. The next_url gets set by Datasette to:

http://localhost:8001/salaries-d3a5631/2017+Maryland+state+salaries?_next=None%2C391&_sort=middle_initial

But then None is interpreted literally and it tries to find a name with the middle initial "None" and ends up skipping ahead to O on page 2.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Ability to sort (and paginate) by column 309471814  
379791047 https://github.com/simonw/datasette/issues/189#issuecomment-379791047 https://api.github.com/repos/simonw/datasette/issues/189 MDEyOklzc3VlQ29tbWVudDM3OTc5MTA0Nw== carlmjohnson 222245 2018-04-09T15:23:45Z 2018-04-09T15:23:45Z NONE

Awesome!

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Ability to sort (and paginate) by column 309471814  
379788103 https://github.com/simonw/datasette/issues/184#issuecomment-379788103 https://api.github.com/repos/simonw/datasette/issues/184 MDEyOklzc3VlQ29tbWVudDM3OTc4ODEwMw== carlmjohnson 222245 2018-04-09T15:15:11Z 2018-04-09T15:15:11Z NONE
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
500 from missing table name 292011379  
379142500 https://github.com/simonw/datasette/issues/193#issuecomment-379142500 https://api.github.com/repos/simonw/datasette/issues/193 MDEyOklzc3VlQ29tbWVudDM3OTE0MjUwMA== carlmjohnson 222245 2018-04-06T04:05:58Z 2018-04-06T04:05:58Z NONE

You could try pulling out a validate query strings method. If it fails validation build the error object from the message. If it passes, you only need to go down a happy path.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Cleaner mechanism for handling custom errors 310882100  
376614973 https://github.com/simonw/datasette/issues/185#issuecomment-376614973 https://api.github.com/repos/simonw/datasette/issues/185 MDEyOklzc3VlQ29tbWVudDM3NjYxNDk3Mw== carlmjohnson 222245 2018-03-27T17:49:00Z 2018-03-27T17:49:00Z NONE

@simonw Other than metadata, the biggest item on wishlist for the salaries project was the ability to reorder by column. Of course, that could be done with a custom SQL query, but we didn't want to have to reimplement all the nav/pagination stuff from scratch.

@carolinp, feel free to add your thoughts.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Metadata should be a nested arbitrary KV store 299760684  
376592044 https://github.com/simonw/datasette/issues/185#issuecomment-376592044 https://api.github.com/repos/simonw/datasette/issues/185 MDEyOklzc3VlQ29tbWVudDM3NjU5MjA0NA== carlmjohnson 222245 2018-03-27T16:38:23Z 2018-03-27T16:38:23Z NONE

It would be nice to also allow arbitrary keys (maybe under a parent key called params or something to prevent conflicts). For our datasette project, we just have a bunch of dictionaries defined in the base template for things like site URL and column humanized names: https://github.com/baltimore-sun-data/salaries-datasette/blob/master/templates/base.html It would be cleaner if this were in the metadata.json.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Metadata should be a nested arbitrary KV store 299760684  
376590265 https://github.com/simonw/datasette/issues/185#issuecomment-376590265 https://api.github.com/repos/simonw/datasette/issues/185 MDEyOklzc3VlQ29tbWVudDM3NjU5MDI2NQ== carlmjohnson 222245 2018-03-27T16:32:51Z 2018-03-27T16:32:51Z NONE

I think the templates themselves should be able to indicate if they want the inherited values or not. That way we could support arbitrary key/values and avoid the application code having special knowledge of license_url etc.

Yes, you could have metadata that works like metadata does currently and inherited_metadata that works with inheritance.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Metadata should be a nested arbitrary KV store 299760684  
370461231 https://github.com/simonw/datasette/issues/185#issuecomment-370461231 https://api.github.com/repos/simonw/datasette/issues/185 MDEyOklzc3VlQ29tbWVudDM3MDQ2MTIzMQ== carlmjohnson 222245 2018-03-05T15:43:56Z 2018-03-05T15:44:27Z NONE

Yes. I think the simplest implementation is to change lines like

        metadata = self.ds.metadata.get('databases', {}).get(name, {})

to

metadata = {
    **self.ds.metadata,
    **self.ds.metadata.get('databases', {}).get(name, {}),
}

so that specified inner values overwrite outer values, but only if they exist.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
Metadata should be a nested arbitrary KV store 299760684  

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

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]);