alphabetically based storage order based on the table names

[bstabler]

from the SATURN team

One suggestion for the next revision to the specification is internal storage of the multiple tables within the OMX file. At the moment, they are stored alphabetically based on the table names so their relative position changes depending on the user-defined title. This causes some problems in implementation for our software as we use their level (ie 1st table, 2nd table, 3rd table) as the unique identifier not the table name (with the latter only optional). To get round this, we export the OMX tables (via UFM2OMX) with a Level position ‘Lxx’ prefix to the user-defined title name. When importing (via OMX2UFM), the levels are simply defined as the order they appear (ie alphabetically) and hence require some post import manipulation. The process works but it’s not as streamlined as it could be. Has anybody else flagged this as weakness?

[markhudson42]

Because I've been using openmatrix a lot lately for rapid import of SATURN UFM data, I have had a trawl (as best as I can) through the openmatrix and PyTables source code and done a bit of googling around and, as far as I can tell, the limitation of tables being returned in alphabetical order of their names is built in to h5py (and maybe HDF5?) itself.
This article says to me that this is just how HDF5 does it.
This StackOverflow answer also says the same kind of thing.

Two years on from your comment, I am assuming that the use of the "Lnn" prefix in the UFM2OMX outputs is finalised now? I have been using this when writing my own library to manipulate the UFM2OMX outputs.

[bstabler]

Hi @markhudson42. I think you need to check with the saturn team - https://saturnsoftware2.co.uk/. We haven't made any revisions to OMX as a result of this suggestion.

[e-lo]

implementation for our software as we use their level (ie 1st table, 2nd table, 3rd table) as the unique identifier not the table name (with the latter only optional)

IMHO, requiring a certain "order" in a serialized data format rather than being able to pull them based on identifier seems like brittle software.

That said, I can see where even in viewing them, you would want to optionally define an order. Thus, i support optionally being able to define an order as a feature.

[pedrocamargo]

I agree with @e-lo on this one. This capability does not seem particularly useful in general cases, so I would simploy close this issue.

[e-lo]

@pedrocamargo - I actually think it could be useful if you store a ton of matrices in a single file. I just also think that the software on the other end shouldn't be so brittle :-)