I hope we all agree that database designers need to be able to specify whether a put through a DB link should trigger processing of the target record or not, hence the PP/NPP flags supported by the DBF_OUTLINK. I don't see any real alternatives to that, a new TPP flag isn't that compelling.
The per-field pp(TRUE) mechanism used for CA put operations does decouple the IOCs from their clients. I'm now particularly possessive of that design but it has worked well enough up to now, and it means that EPICS GUIs never needed to know anything about the database they're connecting to, which I see as a good thing. It might be nice if a database designer could configure that behavior on a per-record-field basis, but implementing that could be tricky and/or slow.
@Michael Does QSRV default to using the pp(TRUE) value? Do any GUIs that support PVA provide the ability to override the process flag?
The isValueField conditional at the end of dbPut() was added so a CA put to a record's VAL field doesn't trigger 2 monitor events, one from dbPut() and the second from the record's monitor() routine called from process(). The first monitor event is suppressed when the target field is VAL and it is marked pp(TRUE) which means a CA put would process the record. My original patch for this undid that suppression if necessary when the put actually comes from a DB link which is NPP.
I hope we all agree that database designers need to be able to specify whether a put through a DB link should trigger processing of the target record or not, hence the PP/NPP flags supported by the DBF_OUTLINK. I don't see any real alternatives to that, a new TPP flag isn't that compelling.
The per-field pp(TRUE) mechanism used for CA put operations does decouple the IOCs from their clients. I'm now particularly possessive of that design but it has worked well enough up to now, and it means that EPICS GUIs never needed to know anything about the database they're connecting to, which I see as a good thing. It might be nice if a database designer could configure that behavior on a per-record-field basis, but implementing that could be tricky and/or slow.
@Michael Does QSRV default to using the pp(TRUE) value? Do any GUIs that support PVA provide the ability to override the process flag?
The isValueField conditional at the end of dbPut() was added so a CA put to a record's VAL field doesn't trigger 2 monitor events, one from dbPut() and the second from the record's monitor() routine called from process(). The first monitor event is suppressed when the target field is VAL and it is marked pp(TRUE) which means a CA put would process the record. My original patch for this undid that suppression if necessary when the put actually comes from a DB link which is NPP.