-
Notifications
You must be signed in to change notification settings - Fork 12
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
How to effectively distinguish sonata file types #243
Comments
Thanks for the issue; I consider
Sure, that makes sense. Returning an enum would make the most sense to me.
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. |
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
The text was updated successfully, but these errors were encountered: