The lower level helpers do not assume anything about the statement that
will be executed. Instead, they take as a parameter the function for
converting the result of the statement to a list of notifications.
Some of the higher level helpers which construct their own queries have
been reimplemented using the lower level helpers and more efficient
returns.
I have taken the opportunity of removing a constraint synonym for a pile
of beam noise by using the constraint synonyms beam itself uses. This
ought to be a little more useful for figuring out how to fulfill these
constraints when they aren't automatically satisfied.
In addition, this PR adds notify' to notify-listen since it was convenient for implementing the above.
I have made a breaking change to the type of deleteAndNotify: Before it would notify and return a primary key unconditionally, but that doesn't make sense to me. It's possible, for example, to delete a row that doesn't exist. That should not emit a notification.
Namely:
The lower level helpers do not assume anything about the statement that will be executed. Instead, they take as a parameter the function for converting the result of the statement to a list of notifications.
Some of the higher level helpers which construct their own queries have been reimplemented using the lower level helpers and more efficient returns.
I have taken the opportunity of removing a constraint synonym for a pile of beam noise by using the constraint synonyms beam itself uses. This ought to be a little more useful for figuring out how to fulfill these constraints when they aren't automatically satisfied.
In addition, this PR adds
notify'to notify-listen since it was convenient for implementing the above.I have made a breaking change to the type of
deleteAndNotify: Before it would notify and return a primary key unconditionally, but that doesn't make sense to me. It's possible, for example, to delete a row that doesn't exist. That should not emit a notification.