OK maybe we can have the best of both worlds.
How about this.
We keep the new DBR_CLASS_NAME request.
In addition the following is implemented:
A new database access routine is provided:
dbSetRecordTypeAttribute(char *recordtype,char *name,char *value);
For example:
dbSetRecordTypeAttribute("mySpecialRecordType","VERS","25.56.456")
Runtime Database access will automatically create attribute RTYP, e.g.
dbSetRecordTypeAttribute("ai","RTYP","ai");
In addition dbNameToAddr (the routine called to locate records a
runtime) will be modified as follows:
If the record is found but the field is not found then it checks to see
if the field name is one of the attribute names. If it is it makes a
"psuedo" field that looks like the following
1) The field type is DBF_STRING
2) It can not be changed, i.e. puts will fail.
3) The value is the attribute value.
Since dbNameToAddr only does this in the case where it finds the record
but not the field, the overhead on an ioc is minimal.
Marty Kraimer
Jeff Hill wrote:
>
> > >From the responses to the message I sent about RTYP there are objections
> > to implementing RTYP via a new DBR_type rather than a new field in each
> > record instance.
> >
>
> There is nothing stopping us from having both a new DBR_xxx type and also a new
> pseudo field name which has storage in the record description, but not in the record
> instance. It appears that there are important uses for both interfaces to the
> system (i.e. links use the new field names, and general purpose clients that do not
> wish to break when the PV name syntax varies will use the new DBR_ type).
>
> Jeff Hill
Chip WATSON wrote:
>
> Marty,
>
> Would it be possible to create a pseudo-field accessable via record.RTYP
> but which is in fact
> implemented in record type structures? Specifically, when the channel
> access server locates
> the record, and discovers it does not have a field of that type, it
> could, before returning an error,
> check if the field name is one of the allowed pseudo-fields (RTYP, VERS,
> etc.).
>
> Chip
- References:
- RE: EPICS r3.13 field VERS Jeff Hill
- Navigate by Date:
- Prev:
Re: processing on put to .VAL field Ned Arnold
- Next:
Re: EPICS r3.13 field VERS Matthias Clausen DESY -MKS-2/KRYK-
- Index:
1994
1995
1996
1997
<1998>
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: EPICS r3.13 field VERS Jeff Hill
- Next:
Re: EPICS r3.13 field VERS Matthias Clausen DESY -MKS-2/KRYK-
- Index:
1994
1995
1996
1997
<1998>
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|