Bug in the read_ldata function

[DaGeibl]

I think noticed a bug in the read_ldata function. I encountered it using the lq_processor for old data(production v1.0) using the newest version of the DataManagement

For version 0.5.5 of the LegendDataManagement this line:
dsp=read_ldata(:dataQC, l200, :jlhit, :cal, period, run, ch)

returned a Table with columns of dsp-parameters and values:
Table with 53 columns and 298468 rows:
blmean blsigma blslope
┌───────────────────
1 │ 1.19915e5 67.0303 -0.000110961 ns^-1

But with version 0.5.6 a Table with the colum dataQC is returned. Its entries are a NamedTuple containing dsp-parameter and its values:
Table with 1 column and 298468 rows:
dataQC
┌───────────────────
1 | (blmean = 1.19915e5, blsigma = 67.0303, blslope = -0.000110961 ns^-1 …

Is this intended behaviour? It got introduced in Pr legend-exp/LegendDataManagement.jl#128.
If yes the processors would need an update.

[theHenks]

From my side this was intended behaviour since the old implementation was a bug. If you access at the moment the hit level with hit = read_ldata(l200, :jlhit, :cal, period, run, ch), you will get a NamedTuple with all the subtables under each key. If you now wanna just access one of the keys with PropSelFunction by parsing the desired key as first argument, you will get the same DataType and structure, just with a selection based on that specific key applied too. This assures type stability and type safety because then every time you query the jlhit tier, you get a NamedTuple as a return independent of what selection you apply to the data.

However, this was not changed by me in the dataflow. This was a mistake and should be fixed there accordingly to make sure that the readin of all jlhit tier levels is working properly again.

[theHenks]

I transfered the issue to the dataflow.

[theHenks]

@jonasschlegel Did this problem not occur in your processing and if you so, did you fix that?