Re: write to a single element of an array field

["Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>]

Some more older background:

The original purpose of the db_field_log (dbf) was to handle monitors without duplicating code. It holds the scalar data that Ralph describes below that gets captured from a field when something calls db_post_events() for that field. Once the data has been saved, an object containing a pointer to it is pushed onto the event queue, and as it comes out the other end the dbf is passed into a call to dbGetField() to the same field. This copies the scalar data out of the dbf and at the same time also grabs any metadata needed from the record for the DBR_* type that was subscribed. The same dbGetField() routine is passed a NULL for the dbf when you do a ca_get(), so in that case the data must be copied straight from the record at the same time as the metadata.

I’m sure Jeff has a different and better solution in his server, but migrating to that would need modifying the server-side filters that are currently using it – there are operational systems now using our filtering, so we will have to maintain compatibility with them for the future.

- Andrew

On Mar 19, 2020, at 1:49 PM, Ralph Lange via Core-talk <core-talk at aps.anl.gov> wrote:

A bit of background:

The name db field log was the traditional one. When adding the filters, I started to do a refactoring of the code to use more comprehensive names for some of the core concepts, and trashed it after a few hours, because I was getting commits that changed every line of the code, which I was sure not to get past QAndrew.

Originally, there had to be two types of updates (field logs):

1. scalar data, where the value and all metadata (incl. timestamp) was in the update, and the post-queue processing was copying data from the update.

2. array data, where the update contained a pointer to the record, and the post-queue processing accessed the record to copy the data out. (into the CA buffers)

When adding filters that are able to change the data and metadata of an array, there is a need for a third type:

3. manipulated array data, where the changed metadata is in the update, and the array data is a copy allocated on the heap, i.e. has to be free()d after post-queue processing.

The admittedly weird way this extension was merged into the original db_field_log structure was intended to keep the changes minimally invasive.

*Sigh*. I know.

~Ralph

-- 

Complexity comes for free, simplicity you have to work for.