BlueBrain / libsonata

A python and C++ interface to the SONATA format
https://libsonata.readthedocs.io/en/stable/
GNU Lesser General Public License v3.0
11 stars 12 forks source link

How to effectively distinguish sonata file types #243

Open jplanasc opened 1 year ago

jplanasc commented 1 year ago

After some internal discussions, we see that we're frequently given a SONATA file in our apps (e.g.: Brayns) and we need to discover its type (usually either circuit or simulation config) by trying both circuit and simulation loaders in libsonata, catching the potential errors and guessing that if the simulator loader triggers an error, we have been given a circuit config. While the approach kind of works for valid config files, it may be giving a misleading error to the user in case we have been given an invalid SONATA config file. Also, we need to do this in different applications, which is starting to make us duplicate code in different apps.

Therefore, I wonder if any of the following ideas would make more sense and would help other applications as well:

  1. Implement a function in libsonata that, given a SONATA file, would return the type of file it is (for example: simulation config, circuit config, node file, report, ...) as an ENUM, a string or similar.
  2. Migrate SNAP's validator function (circuit_validation) to libsonata (in C++) and implement the equivalent functionality for simulation config.

Any thoughts? Thanks! @jamesgking @pramodk @jdcourcol @mgeplf

mgeplf commented 1 year ago

Thanks for the issue; I consider libsonata a shared resource, and when teams need to add functionality, they are welcome to contribut it as they come across problems - so this is great.

Implement a function in libsonata that, given a SONATA file, would return the type of file it is (for example: simulation config, circuit config, node file, report, ...) as an ENUM, a string or similar.

Sure, that makes sense. Returning an enum would make the most sense to me.

Migrate SNAP's validator function (circuit_validation)

This would be quite a bit of work, and I'm not sure that it would be worth it. It's purposefully written to be separated from the other convenience methods, so that we have a baseline of 'correctness'. Most of the config checking, however, has been moved out of the SNAP, as libsonata's config parsers should be catching all the errors - if they aren't they should be improved, IMO.

jplanasc commented 1 year ago

Thanks @mgeplf for your inputs. I think both options would work for our use case, so if you prefer the first one, I have no objections to that.

mgeplf commented 1 year ago

I think both options would work for our use case, so if you prefer the first one, I have no objections to that.

Sounds good, please add me to the review when you want me to look at something.

mgeplf commented 1 year ago

Any updates on this @jplanasc?

jplanasc commented 1 year ago

@mgeplf I've had no time to dedicate to this, sorry.

mgeplf commented 1 year ago

Ok, no problem.