Open jplanasc opened 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.
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.
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.
Any updates on this @jplanasc?
@mgeplf I've had no time to dedicate to this, sorry.
Ok, no problem.
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:
Any thoughts? Thanks! @jamesgking @pramodk @jdcourcol @mgeplf