issue_comments

I do think this needs type checking - I just tried and you really can send a string to an integer column and have it work, which feels bad.

I've decided that I won't do that validation for the first version of this - I'm going to teach dclient to send the correct types instead: https://github.com/simonw/dclient/issues/6#issuecomment-1330963953

If I do that I should probably update insert to do those validation checks as well.

... which does imply that I'm going to do an extra layer of validation over what SQLite provides. SQLite will happily allow a text string to be added to a supposedly integer column. I'm not going to allow that - I'll return a validation error instead, unless the string can be safely coerced to the correct type.

Had a design conversation with myself in https://github.com/simonw/dclient/issues/6 where I decided that the API should allow string values to be sent to integer columns which would be automatically converted if possible to do so - as an API usability feature.

Incomplete implementation of this view: ```python class RowUpdateView(BaseView): name = "row-update"

def __init__(self, datasette):
    self.ds = datasette

async def post(self, request):
    database_route = tilde_decode(request.url_vars["database"])
    table = tilde_decode(request.url_vars["table"])
    try:
        db = self.ds.get_database(route=database_route)
    except KeyError:
        return _error(["Database not found: {}".format(database_route)], 404)

    database_name = db.name
    if not await db.table_exists(table):
        return _error(["Table not found: {}".format(table)], 404)

    pk_values = urlsafe_components(request.url_vars["pks"])

    sql, params, pks = await row_sql_params_pks(db, table, pk_values)
    results = await db.execute(sql, params, truncate=True)
    rows = list(results.rows)
    if not rows:
        return _error([f"Record not found: {pk_values}"], 404)

    # Ensure user has permission to update this row
    if not await self.ds.permission_allowed(
        request.actor, "update-row", resource=(database_name, table)
    ):
        return _error(["Permission denied"], 403)

    body = await request.post_body()
    try:
        data = json.loads(body)
    except json.JSONDecodeError as e:
        return _error(["Invalid JSON: {}".format(e)])
    if not isinstance(data, dict):
        return _error(["JSON must be a dictionary"])

    def update_row(conn):
        sqlite_utils.Database(conn)[table].update(pk_values, updates)

    await db.execute_write_fn(update_row)
    result = {"ok": True}
    if data.get("return"):
        result["row"] = {"row-here": "TODO"}
    return Response.json(result, status=200)

``` This is before the refactor in: - #1896

In trying to write this I realize that there's a lot of duplicated code with delete row, specifically around resolving the incoming URL into a row (or a database or a table).

Since this is so common, I think it's worth extracting the logic out first.

If the update succeeds it will return {"ok": true}.

For consistency with /db/table/-/insert you can pass "return": true and it will return a "row" key with the now-updated full row.

I'm also not going to implement "alter": true yet (which would add any missing columns based on the update) - I'll hold that off for a later feature.

I'm going to use the error format I've been experimenting with here: - #1875

json { "type": "https://example.net/validation-error", "title": "Your request is not valid.", "errors": [ { "detail": "must be a positive integer", "pointer": "#/age" }, { "detail": "must be 'green', 'red' or 'blue'", "pointer": "#/profile/color" } ] } I'm not quite ready to commit to a type URL though, so I'll leave that to be solved later should I fully embrace that RFC.

The initial design I'm going to implement will look like this:

POST /db/table/1/-/update Authorization: Bearer xxx Content-Type: application/json json { "update": { "name": "New name" } } Any fields that are not yet columns will return an error.

Should it enforce types, in as much as an integer column should have a JSON integer passed to it, or should it allow strings containing valid integers?

I'm going to allow strings, mainly as a workaround for the fact that JavaScript integers have a maximum size.

I'm not going to allow updates to primary keys. If you need to do that, you can instead delete the record and then insert a new one with the new primary keys you wanted - or maybe use a custom SQL query.

Thinking more about validation: I'm considering if this should validate that columns which are defined as SQLite foreign keys are being updated to values that exist in those other tables.

I like the sound of this. It seems like a sensible default behaviour for Datasette. And it fits with the fact that Datasette treats foreign keys specially elsewhere in the interface.

The id=(int, ...) thing is weird, but is apparently Pydantic syntax for a required field?

https://cs.github.com/starlite-api/starlite/blob/28ddc847c4cb072f0d5d21a9ecd5259711f12ec9/docs/usage/11-data-transfer-objects.md#L161 confirms:

1. For required fields use a tuple of type + ellipsis, for example (str, ...).
2. For optional fields use a tuple of type + None, for example (str, None)
3. To set a default value use a tuple of type + default value, for example (str, "Hello World")

python print(create_model('document', id=(int, ...), title=(str, None)).schema_json(indent=2)) json { "title": "document", "type": "object", "properties": { "id": { "title": "Id", "type": "integer" }, "title": { "title": "Title", "type": "string" } }, "required": [ "id" ] }

I'm considering Pydantic for this, see: - https://github.com/simonw/datasette/issues/1882#issuecomment-1302716350

In particular the create_model() method: https://pydantic-docs.helpmanual.io/usage/models/#dynamic-model-creation

This would give me good validation. It would also, weirdly, give me the ability to output JSON schema. Maybe I could have this as the JSON schema for a row?

/db/table/-/json-schema