> On Aug 16, 2023, at 1:35 PM, Adrian Klaver <adrian.kla...@aklaver.com> wrote:
>
> On 8/16/23 12:01, Rob Sargent wrote:
>> On 8/16/23 12:30, Guyren Howe wrote:
>>> For some reason, I was thinking the rule could see just the fields from the
>>> command, but you’re right; a rule won’t work. Sorry.
>>>
>>> Guyren G Howe
>>> On Aug 15, 2023 at 23:22 -0700, Russell Rose | Passfield Data Systems
>>> <russellr...@passfield.co.uk>, wrote:
>>>> I have just had a quick look at rules and I am not sure how it can be
>>>> done. Rules still use the concept of NEW and OLD. If my original row has
>>>> 'myfield' set to 'me' then I don't think I can tell the difference between:
>>>>
>>>> Update mytable set afield='something'
>>>> and
>>>> Update mytable set afield='something',myfield='me'
>>>>
>>>> Within the rule I think NEW.myfield will be set to 'me' in both cases.
>>>> Please can you explain how I can tell the difference between the two
>>>> update statements
>>>>
>> If the original value in the user column is "me", what is the difference
>> between "set other_column = some_value, user = 'me'" and "set other_column =
>> some_value" at the business level?
>
> Affirmation that the user updating the record explicitly set the user value.
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
Agreed. But at the end of the day, the difference is what exactly? Wouldn't
auditing (short of sql logging) say “no change” with respect to “me” column?
This then is a client issue, no? There has to be two paths in the client code,
one which generates an update without “me” and one which includes “me" and the
second path does not take in to account current value. If it’s worth the
effort the latter code path needs to be cognizant of the current state of the
record (“me” column).
