Fix a footgun in before-update

[johnswanson]

In a very precise condition, we would emit an UPDATE clause without
any WHERE condition at all:

• the before-update method's result does not have a primary key

• the where clause in an update! call matches multiple rows

• some part of the update map will change all matched rows

• another part of the update map will change only a subset of matched
  rows

If all these conditions are met, the bug is triggered and we emit an
UPDATE without any WHERE clause at all.

This fixes the issue by making sure to get the primary keys from the
realized row rather than from the result of
(before-update (merge realized-row changes)). I also added tests as
well as an assertion that a primary key is actually present, since its
absence is so dangerous.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.56%. Comparing base (edee4e0) to head (118c6aa).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
- Coverage   83.60%   83.56%   -0.04%     
==========================================
  Files          37       37              
  Lines        2501     2501              
  Branches      212      213       +1     
==========================================
- Hits         2091     2090       -1     
  Misses        198      198              
- Partials      212      213       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[camsaul]

This seems like it's changing a lot of behavior, the old code realized the row and then used that as row everywhere, the new code keeps realized-row separately but doesn't thread that thru to everything else like it did before.

It probably doesn't make a difference since under the hood the underlying transient Row object should know it was already realized elsewhere and return the realized version but I think by making the change I suggested it would make the code a little clearer and eliminate a little bit of overhead

[johnswanson]

This seems like it's changing a lot of behavior, the old code realized the row and then used that as row everywhere, the new code keeps realized-row separately but doesn't thread that thru to everything else like it did before.

It probably doesn't make a difference since under the hood the underlying transient Row object should know it was already realized elsewhere and return the realized version but I think by making the change I suggested it would make the code a little clearer and eliminate a little bit of overhead

Doh, yeah - sorry about that!

[johnswanson]

@camsaul it looks like MariaDB has changed the error format from

Unknown column 'venue_name' in 'SET'

vs

Unknown column 'venue_name' in 'field list'

in the test case between 11.3 and 11.4 - locally things pass if I run mariadb:11.3 but fail if I run mariadb:11.4. Just pushed a commit that should fix that.