Miss Dada  🏳️‍⚧️

so rails has added another race-condition-having insert API to replace its existing race-condition-having insert API further material for the article I'm working on about how the type { read() -> T, write(T) } cannot possibly provide consistency

essentially, because find_or_create has race conditions, they've added create_or_find, which has... different race conditions you do not actually want some combo of read-or-write, you want insert-or-update, in a single query if possible, or transactionally otherwise

and it does the initial INSERT in its own transaction which the on-failure SELECT is not part of, which admits races if the record is deleted, regardless of isolation level

and on mysql it means the caller can't fold this into their own transaction

To be fair, there's not really any way to write `find_or_create` that isn't racy. Closest you can get (that works on both pg and mysql) is a select for update, followed by an insert ignore, followed by another select -- but even that can fail

I know that, but create_or_find is also racy, and its own docs say as much, so I'm confused about why it's been added if I wanted consistency I wouldn't use either of these APIs

I am definitely not advocating that `create_or_find` is a good API. I argued against adding it at the time. For real improvement to happen though, I think Rails needs to:

- Become more comfortable with APIs that are coupled to a single DB. Upsert in particular is really tricky, and the number of DB agnostic APIs you can build for it are *extremely* limited - Build more APIs focusing on the DB as the source of truth.