Open coolreader18 opened 1 month ago
Please also update the API proposal
Should we change the API? If updates are only by PK, and a table has at most one PK, then they don't really belong on unique indices, do they? Should it be ctx.db.my_table().update(new_row)
rather than ctx.db.my_table.().my_pk_field().update(new_row)
?
EDIT: Or do we want to leave it on the PK index to make it clear how the old row is found during the update?
Or do we want to leave it on the PK index to make it clear how the old row is found during the update?
I think that's beneficial - I just added a section in the doc comment for update()
about what's considered an update and why it only exists on the primary key. We could probably consider adding .update()
on the table in the future, if it's enough of a ergonomics thing.
Description of Changes
@cloutiertyler and I were talking about this. Makes the semantic mapping for people easier, a row update on the client is an update() on the server. Doesn't make sense for non-pk to have
.update()
but it doesn't trigger an update.Expected complexity level and risk
1