GDD: Store reference to gddEnumStringTable in aitEnum16 ?

The current design is to cache the enum string table in the server and provide it as an extra argument to the conversion routines.

edited on: 2005-10-27 10:47

After I patched the example server so that it would not change the
native type of the PV to double I can now use it to demostrate that
the following correct sequence of events occurs when a client requests
a PV with native type aitEnum be converted to external client type
DBR_STRING.

o The CA server creates the destination GDD with proper application type
and with primitive type wildcarded.
o CA server calls the server tool's read VF with this GDD as the destination
o Server tool copies into this GDD setting it to the native type (in
this case aitEnum)
o The CA server calls aitConvert() to convert this GDD to a DBR_STRING
using an enumeration sting table that it has cached (this cache is
of course initialized by calling the server tool's read VF).

This is exactly how Jim and I originially intended for eneumerated types
to be implemented.

Its true that gdd::smartCopy() provides a nill enumeration string table
to aitConvert(), but this should presumably be a non-issue for the GW
since it should be preserving the native type (in this case aitEnum)
for all of its internal PV.

Since the GW should not be storing a PV with corresponding native
type in the IOC is enumerated in type string then smartCOPY shouldnt
need to have an enumerated string table argument.

If the GW were to allow the primitive type of its GDD storage for a
PV that is enumerated to stray off of aitEnum then trouble is probably
guaranteed.

That issue probably needs to be pursued in the GW.

The problem with storing a reference to gddEnumStringTable in aitEnum16
(in the GDD) is that you either have to store a copy or a reference. If
you store a copy there is too much overhead. If you store a reference
there are too many problems with a GDD ending up using a dangling reference
to a string table that no longer exists. To avoid a very complex interface
for users we decided to go with a solution caching the string table in
the server.

edited on: 2005-10-27 18:25

Ken: Perhaps you could place a small debugging code in the GW which prints a message if the native type of a PV's GDD isn’t the same as the native type in the IOC. After doing this you could run ca_test and acctst against the GW to see if this is in fact occurring.

From Dirk,

 From Jeff's Mantis Notes:
> Its true that gdd::smartCopy() provides a nill enumeration string
> table to aitConvert(), but this should presumably be a non-issue for
> the GW since it should be preserving the native type (in this case
> aitEnum) for all of its internal PV.

This conversion only happens when an alarm handler is connected. The
reason is that in this case, we have a container holding data for
dbr_stsack_string. This structure stores the value as a string, not in
it's native type. Only in this case, gdd::smartCopy() is called.
Normally, when no alh is connected, the gateway indeed holds all data in
its native type and smartCopy() is not used.

In my opiniton, a generic function like smartCopy() does not make much
sense when it can't be called generically with all data types. All
generic clients, like gateway, have to check now if their data is
compatible with the generic function and have to handle conversions enun
to string separately.

If the gateway (or any other generic client) should hold the data in its
native type even when alh is conencted, is a different question (in
fact, it is mantis entry 213).

That's actually how I found out where the problem is. See above.

The problem with storing a reference to gddEnumStringTable in aitEnum16
(in the GDD) is that you either have to store a copy or a reference. If
you store a copy there is too much overhead. If you store a reference
there are too many problems with a GDD ending up using a dangling reference
to a string table that no longer exists. To avoid a very complex interface
for users we decided to go with a solution caching the string table in
the server.

This is the types of problem that Data Access was intended to solve

edited on: 2005-11-09 08:20

> In my opiniton, a generic function like smartCopy() does not make much
> sense when it can't be called generically with all data types. All
> generic clients, like gateway, have to check now if their data is
> compatible with the generic function and have to handle conversions enun
> to string separately.

I can see some validity in this argument. I did not write GDD and
can also pick at other issues that arrise from its use. IMHO we should switch
to Data Access and move away from GDD. Therefore, I am inclined to fix GDD
to work correctly the way that Jim orginally designed it, but not try to
reengineer it.

> If the gateway (or any other generic client) should hold the data in its
> native type even when alh is conencted, is a different question (in
> fact, it is mantis entry 213).

Yes, the native type of an enum PV (stired in a GDD) should not change
because, at a minimum, it confuses future clients. Of course, this kind
of modal behavior is not a positive feature of GDD.

And if we fix mantis entry 213 in the GW then the current behavior of
GDD should be sufficent for the needs of the GW and hopefully all other
server tools.

The bottom line is that we dont have an infinite amount of resource such
that we can redesign GDD

edited on: 2005-11-15 14:16

I consider the GDD behavior described by Mantis 212 to be per Jim's original
design, and therefore dont consider it to be a bug.

I am therefore marking this entry as "not-a-bug", but it could always be
reopened if we decide otherwise.

Proper response of the GW to an alarm ack can be fixed by addressing
mantis #213

R3.14.8 Release.