Re: ETags, If-Match and database versions

As clarification (you are no doubt aware), all the processing around the
actual format of the ETag itself (whether weak or strong) is up to you -
you could use the DB version field or you could create a hash of the fields
(names and/or values) or indeed, anything else you want. Or you could just
pass a string "Graham is cool v1". You have complete control.

On Sat, Dec 28, 2024, 6:34 AM Michael Sweet <msweet@msweet.org> wrote:

> Graham,
>
> > On Dec 28, 2024, at 7:08 AM, Graham Cox <graham@grahamcox.co.uk> wrote:
> > ...
> > I've also seen the suggestion to append a server version to the etag to
> avoid this, but there are significantly more reasons to change the server
> version that *wouldn't* change the JSON representation. And doing that
> would then mean every time the server version changes then all the etags
> would change, which would mean that caching and optimistic locking breaks -
> often needlessly...
>
> Don't make it the actual server software version, make it an encoding
> version number that changes only when the generated content changes - that
> is something you can create a unit test for (and thus be alerted when you
> need to change the number) and that could also handle potential DB schema
> changes, i.e., if you add a field/column but not remove/rename things.
>
> ________________________
> Michael Sweet
>
>
>