I suspect that storing the version in a record type specific string would result in too
much flexibility. How will CA client applications determine if the version is greater
than some number without making the string parsing code specific to the particular
record type.
I am still in favor of two integer pseudo fields for the version info. One for
the major version number and one for the minor version number. This
would require a slightly different API.
dbCreateRecordTypeAttribute (char *recordtype, char *name, unsigned DBF_type, void *value);
Jeff
On Wednesday, February 04, 1998 7:27 AM, Marty Kraimer [SMTP:[email protected]] wrote:
> 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
- Navigate by Date:
- Prev:
error in iocLogServer.c Pete Jemian
- Next:
RE: error in iocLogServer.c Jeff Hill
- 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 Pete Jemian
- Next:
RE: EPICS r3.13 field VERS Tim Mooney
- 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
|