Commits on Apr 19, 2024

1. Have client insert functions return insert result instead of raw job … …

   …row (breaking)
   
   This one's aimed at resolving the problem described in this discussion
   [1]. In short, when an inserted job with unique properties in skipped
   because it was a duplicate, there's no easy way to ascertain through
   River's API that this is what happened.
   
   The cleanest resolution is what's proposed here. Instead of returning a
   raw `JobRow`, insert functions return a `JobInsertResult` that contains
   a job row, along with a boolean indicating whether an insertion was
   skipped due to a duplicate unique. The result struct is also better for
   future compatibility in that it could contain other metadata pertaining
   to job insertions.
   
   The downside of this approach is that it's a breaking change. The hope
   is that it's not _that_ bad of a breaking change because most of the
   time callers don't care that much about properties on a return result
   row given they just sent most of it as a parameter to `Insert`, so they
   might not be accessing any return values and therefore not be broken.
   
   You can get a rough idea for changes in callers by looking at what
   changed in this diff. `client_test.go` needed quite a few tweaks because
   it's doing some more comprehensive testing, but only one example test
   (more representative of user code) had to change, which is a good sign.
   
   [1] #86

   

   brandur committed Apr 19, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for b847215
   • Browse repository at this point

   Copy the full SHA

   b847215 View commit details

   Browse the repository at this point in the history