info field may be bound to alias instead of record

[Dirk Zimoch]

In a record like this (modified dbStaticTest.db)

record(x, "testrec") {
    alias("testalias")
    info("A", "B")
}

The info field "A" is not bound to the record "testrec" but to the alias "testalias".
This modification (swap order of alias and info) makes the dbStaticTest fail.

The reason is that the dbCreateAlias function overwrites the DBENTRY which is passed by reference. Thus any info() after alias() is bound to the most recent alias name.

The attached patch (for 3.16) contains the modification to dbStaticTest.db which makes the test fail as well as the fix of dbCreateAlias which makes the test succeed again.

I noticed this when adding info access in https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+ref/info_fields, thus the fix is included there as well.

[Andrew Johnson (anj)]

I can replicate this problem and your fix works fine, but it's doing a bit more work than it actually needs to. I'm going to commit a streamlined (and cleaned up) version of dbCreateAlias() to the 3.15 branch and merge it up (there were other changes to it between 3.14 and 3.15 that I just decided I don't want to deal with).

Note that the dbStaticTest.db file only exists on the 3.16 branch, and I don't want to add it during the merge up from 3.15, so the automated test will only appear when we merge your info_fields branch. My changes to dbCreateAlias() will conflict with yours in that branch, but I will correct that during the merge (the Merge Request will probably start to show a conflict, which you can ignore).

I wonder if we'll ever find a use for creating an info field on an alias? With this fix there shouldn't be any way to create one from a .db file, but it will still be possible.

[Dirk Zimoch (dirk.zimoch)]

> I wonder if we'll ever find a use for creating an info field on an alias?
I don't think so. In my understanding the alias and the record were supposed to be "the same thing".

[Ralph Lange (ralph-lange)]

Possible use case:
Info items are a good way to configure which records should be visible through a directory service. (Often those are the "public API" of a database.)
If you want to register your record to different directory services (name spaces) under different names - voilà!

(Of course, this function can be implemented using multiple info items on "the same thing" record.)

[Dirk Zimoch (dirk.zimoch)]

Somehow I doubt that this was the original intention.

[Ralph Lange (ralph-lange)]

At NSLS-II, info items are used to configure the mechanism that uploads record names to the ChannelFinder based directory service.
Also at NSLS-II (and at ITER), aliases are used to make a single record available through different names, following different naming conventions.

As far as I know, they don't run separate directory instances yet, but that would be only a small step.

[Dirk Zimoch (dirk.zimoch)]

So you feel this is not a bug? In that case it should be made clear in the documentation what the implications of the order of info and alias statements are. In particular that any info item after an alias statement is bound to the alias name, not to the original record name.

[Ralph Lange (ralph-lange)]

Sorry for the confusion:
I was only answering to your statement (in response to Andrew) that you don't think we will ever find a use for creating an info field on an alias.
There are use cases, and I was giving an example.

In the current situation, I agree that this was not intended and should be treated as a bug.
As long as it will still be possible in case we want to add the info-on-alias feature, and as long as for existing use cases there are designs/implementations that don't need it, the proposed changes are fine with me.

[Dirk Zimoch (dirk.zimoch)]

One could make alias-infos explicit with something like this:
record (...) {
  alias(aliasname) {
    info(alias-info, "This is an info for the alias only")
  }
  info(record-info, "This is an info for the record")
}

Also I don't mind if you decide that the previous behavior is not a bug but a feature. But the difference is that a feature is documented behavior while a bug is undocumented behavior.

I just noticed this behavior when testing dbli and found it surprising.

[Andrew Johnson (anj)]

Yes, this was a bug in the original implementation. I committed the fix to the 3.15 branch and merged it into 3.16 on Friday.

I asked the question about attaching info items to aliases in case we switch to an alternative way to attach info items to records that would prevent their being attached to aliases. Moving the ELLIST infoList from struct dbRecordNode to a dbCommon field would save memory and make a faster info API possible from just a precord pointer (this wasn't possible when info's were originally added as we still had 2 different in-memory representations for a record instance back then).