We need editable tables, that’s really a killer feature of notion. That you can sql select some data, and the results you get back, are actually mutable in place. So let’s try and implement that.

Let’s build a table real quick with some notable properties:

• a non mutable field (id)
• a mutable object attribute (title)
• oh wait, we have three variants of that mutable object attribute, and the edit should essentially go to the last one.
• a tag based attribute
• a tag based attribute that I didn’t used to fill in automatically so will be missing in places.

we’ll need to

• add ID to every query, just, as a dupe, and then extract that into the ResultSet
• add that into the HTML
• a new /patch route that accepts a tuple (id, column, value)
• JS to enable this

Misc Thoughts

we do sort of want to communicate to the frontend what the type of that column is. We’ll need that for someday-UI, is it a status tag (enum) that needs to be rendered with the select box when clicked on?

Do we care that this impacts ‘real’ sql queries? Or do we operate under the assumption that $someday we’ll have a UI that hides the SQL and correctly applies GROUP/SQL based on

Work Log

gantt
    dateFormat X
     axisFormat %b %dm- %Hh%M
    title Gantt
        ⏰ progress on editable tables : bc71f53c-8c6b-4e26-855d-9e8143e9b899, 1738568581, 1738575197
    click bc71f53c-8c6b-4e26-855d-9e8143e9b899 href "/penemure/note/bc71f53c-8c6b-4e26-855d-9e8143e9b899.html"