-
Notifications
You must be signed in to change notification settings - Fork 24
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
omego --omerosql option exposure #4
Comments
E.g. https://github.com/dpwrussell/omero-server-docker/tree/sql-file Name of the file could be fixed, controlled by an environment variable or both. The logic of the upgrade could also be rearranged if made slightly more complicated. e.g.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am currently overriding the
60-database.sh
startup file completely because in my case I may be restoring a database rather than creating a new one from scratch. Building from a specific SQL file might be a useful thing to be able to do in general though (e.g. for diagnosing a server where you have been given a dump) and I could also make use of that.omego
has an option--omerosql
which does exactly that, but the question would be: How to expose that at container instantiation time. A simple way would be to designate a place where a SQL file could be placed using a volume mount (or other technique, in my case an earlier startup script might have fetched it to the prescribed location from S3), and if present will be used instead of creating a fresh database if that file exists.Any thoughts?
The text was updated successfully, but these errors were encountered: