You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no option to force annatto to build the corpora in memory. The annotation graph is always initialized on disk. For machines with larger memory this is a waste.
For now I would really like to avoid configuration files, having a single binary is neat. I suggest an optional argument (--in-mem) or an environment variable (ANNATTO_IN_MEM=true), of which the latter might be the more suitable way to go for server applications. A third option would be to initially deserialize a template for AnnotationGraph where the storage location is predefined.
If we are not using config files yet, both variants can be achieved at the same time with structopt by using an environment variable fallback for the configuration option: https://docs.rs/structopt/latest/structopt/#environment-variable-fallback. We might have to update structopt to use this feature.1
I would keep the issue with a configurable storage location separate and implement the in memory switch first.
Footnotes
It seems that structopt is now in maintenance only mode and considered feature complete. If we would need more features, the clap crate is recommended. Since all features we currently need are included, I think we can stay with structopt for now. ↩
Currently there is no option to force annatto to build the corpora in memory. The annotation graph is always initialized on disk. For machines with larger memory this is a waste.
For now I would really like to avoid configuration files, having a single binary is neat. I suggest an optional argument (
--in-mem
) or an environment variable (ANNATTO_IN_MEM=true
), of which the latter might be the more suitable way to go for server applications. A third option would be to initially deserialize a template forAnnotationGraph
where the storage location is predefined.Any thoughts @thomaskrause ?
The text was updated successfully, but these errors were encountered: