-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NTTable fields are sorted alphabetically instead of by insertion order #87
Comments
I think an example, or better a unittest case, will be necessary. I extended the |
I'm having some trouble with expressing it as a test, but I have a reproducer:
Macros
Macros
The behavior is the same if you switch A for "event" and B for "timestamp", which were the values I had trouble with when opening this issue. As you can see, in the first case, everything is coherent: the first column is "value.A", it's shown that way in In the second case, that's no longer true: the first column is still "value.A", even though it was defined afterwards. EDIT: I reread the commit adding more testing and managed to write out my own in #95 |
Aside: I realized I was required to have the data records NELM>1 for Is this a limitation related to #69 ? Or a separate bug? |
Describe the bug
I have a table with "Timestamp" and "Event" columns, and originally used
"value.A"
and"value.B"
for its columns. However, after taking a look at the spec, which mentions thatI thought it might make sense to get more descriptive value names:
"value.timestamp"
and"value.event"
. However, that broke my NTTable.My database declares the timestamp waveform before the event one, but
pvinfo
now lists the fields in the wrong order, and the values are indeed switched inpvget
/pvmonitor
output:To Reproduce
Seems trivial, but I can provide a minimal example if necessary.
Expected behavior
I would have expected the field ordering to respect my declaration order. I don't know if that's actually viable, though, given that users probably expect declarations using
value.[A-Z]
to be properly sorted...I tried using epics-base's implementation to compare, but it simply tells me
"value.timestamp"
is an invalid field name. So it seems to requirevalue.[A-Z]
.If sorting is required, I think reasonable fixes could be simply rejecting more complex value field names, or documenting that sorting always happens, so custom field names have limited usefulness.
Information (please complete the following):
The text was updated successfully, but these errors were encountered: