EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Database Field type in db_access.h
From: "Mooney, Tim M." <[email protected]>
To: Michael Davidsaver <[email protected]>, Jeong Han Lee <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Wed, 3 May 2017 15:45:25 +0000
re...

> What I meant to say is that I think that DBF_NO_ACCESS could be removed
> as it isn't useful.  I suspect that it exists as a historical echo of
> DBF_NOACCESS in dbAccess.h, which signifies a DB field where the storage
> can't be directly converted to one of the other DBF_* types (eg TIME in
> dbCommon.dbd or VAL in waveformRecord.dbd).

It's useful for autosave.  I need to know if a field whose value is to be restored
isn't ready to be written to yet (before record init), because its field type hasn't
been set, or its array space hasn't been allocated. 

Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: [email protected] [[email protected]] on behalf of Michael Davidsaver [[email protected]]
Sent: Wednesday, May 03, 2017 10:13 AM
To: Jeong Han Lee
Cc: [email protected]
Subject: Re: Database Field type in db_access.h

On 05/03/2017 09:27 AM, Jeong Han Lee wrote:
> Hi Michael,
>
>
>
>>>
>>>   Please look at db_access.patch, and let me know what you think.
>>>
>>>   LAST_TYPE should be DBF_NO_ACCESS instead of DBF_DOUBLE, is it right?
>>
>> The present definition looks correct to me.  It did confuse me for a
>> moment until I noticed the '<='
>>
>>> #define    VALID_DB_FIELD(x)    ((x >= 0) && (x <= LAST_TYPE))
>
>
>   I don't follow your explanation. The present definition is following :
>
>
> #define DBF_STRING    0
> #define    DBF_INT        1
> #define    DBF_SHORT    1
> #define    DBF_FLOAT    2
> #define    DBF_ENUM    3
> #define    DBF_CHAR    4
> #define    DBF_LONG    5
> #define    DBF_DOUBLE    6
> #define DBF_NO_ACCESS    7
> #define    LAST_TYPE    DBF_DOUBLE
> #define    VALID_DB_FIELD(x)    ((x >= 0) && (x <= LAST_TYPE))
> #define    INVALID_DB_FIELD(x)    ((x < 0) || (x > LAST_TYPE))
>
>   If this is correct, what is DBF_NO_ACCESS within that definition? Is
> it in INVALID_DB_FIELD?

My explanation was somewhat truncated as I looked for an example of
where I knew that (IN)VALID_DB_FIELD() should be used, and found that it
wasn't (a bug).

What I meant to say is that I think that DBF_NO_ACCESS could be removed
as it isn't useful.  I suspect that it exists as a historical echo of
DBF_NOACCESS in dbAccess.h, which signifies a DB field where the storage
can't be directly converted to one of the other DBF_* types (eg TIME in
dbCommon.dbd or VAL in waveformRecord.dbd).

On the db_access.h side there is at present no real concept of this.
The DBF_* types are used is when mapping to a DBR type, eg.
dbf_type_to_DBR_TIME().

> dbf_type_to_DBR_TIME(DBF_DOUBLE) -> DBR_TIME_DOUBLE

So the fact that DBF_NO_ACCESS doesn't (and imo can't) map to any DBR_*
makes it useless.

Note that DBF_NOACCESS is handled in dbAccess.c with INVALID_DB_REQ(),
eg. in dbGet()

These analogous definitions are found in dbFldTypes.h


>> And similarly in dbf_type_is_valid().
>>
>
>   Yes, I saw the similarity in dbf_type_is_valid().  In addition,
> However it is inconsistent if we compare DBR_*  with DBF_*. That is the
> first very naive thought I had to create a patch. Then I think, it is
> more than what I think as usual.
>
>
>   I found the interesting discussion in tech-talk.
>   http://www.aps.anl.gov/epics/tech-talk/2002/msg00137.php
>
>
>> It's actually not apparent to me that 'DBF_NO_ACCESS' can have any valid
>> use.  Other than appearing in dbf_text[] it doesn't seem to do anything.
>
>
>
>>
>>
>> And hey, what do you know.  RSRV isn't bounds checking the requested DBR
>> type code in event_add_action(), read_notify_action(), or read_action().
>>  It uses the dbr_size_n() macro which doesn't bounds check it's first
>> argument, or look for overflow.
>>
>>
>> ...
>>>   I didn't commit my change anywhere, so I just generated the
>>> db_access.patch via
>> ...
>>>   I just execute the following command (got from Michael)
>>> $ git format-patch -k -1
>>
>> I should have mentioned that this command is only useful after you
>> commit.
>
>   I though so, but I prefer not to commit anything to anywhere. :) Once
> I understand the epics base better than, I will use this command to
> create a patch for the community. Thank you again.
>
>   Thanks,
>   Han
>
>
>
> P.S. Is this right place to discuss this subject? Or do anyone want me
> to move this subject to the normal tech-talk?  It is the sort of
> question, which I have now, while I am studying more EPICS itself.

I'm not sure there is a "right" place.  I suppose it's a question of
whether you're happy with the response you get ;)


Replies:
Re: Database Field type in db_access.h Michael Davidsaver
Re: Database Field type in db_access.h Michael Davidsaver
References:
Database Field type in db_access.h Jeong Han Lee
Re: Database Field type in db_access.h Michael Davidsaver
Re: Database Field type in db_access.h Jeong Han Lee
Re: Database Field type in db_access.h Michael Davidsaver

Navigate by Date:
Prev: Re: Database Field type in db_access.h Michael Davidsaver
Next: Re: Database Field type in db_access.h Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Database Field type in db_access.h Michael Davidsaver
Next: Re: Database Field type in db_access.h Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024