Is this really the same return signature the DB gives? I believe you have to check the affected rows of theExec as it will not return an error, just zero affected rows.

I wonder if we rely on similar assumptions elsewhere in the code, seeing as the generated code doesn't check affected rows 🤔

Other dbmem queries have very similar logic; I just copied it.

Ideally we should change it so that our dbmem logic matches reality. Otherwise a developer may rely on this behavior and wonder why it doesn't work in the real world.

I'll file a follow-up issue 👍
EDIT:#11263

review: calling this out here -- I had assumed that the index over(name, tags["owner"]) would disallow multiple rows with("foo", NULL) but this is apparently not the case. However, it does disallow multiple rows with("foo", "").

I updated to useMutateProvisionerTags wherever possible when inserting a provisioner daemon.

@mafredri helpfully pointed out that we can useCOALESCE in the index to ensure that an absent value is treated the same as an empty string. 🎉 Adding a migration for this now.

review: another call-out: I am now setting the ID of the provisionerd server to be the same as the provisioner daemon that was inserted into the database, instead of a random UUID as it was before.

Ibelieve this should be OK, but deferring to better judgement here.

Ideally we should change it so that our dbmem logic matches reality. Otherwise a developer may rely on this behavior and wonder why it doesn't work in the real world.

This makes it much more clear what it's purpose is ❤️

Noticed this wass.timeNow(), but turned intotime.Now(). I suppose that's OK? Should it bedbtime.Now(), though?

Should be s.timeNow, will hotfix 👍 Thanks for the catch