Affects Version/s: OpenMRS 2.0
Fix Version/s: OpenMRS 2.1
Sprint:OpenMRS 2.1 Release
The process created in
RA-218 to auto-generate demo data is slow and ends up making different data each time, so using demo data is cumbersome and the data you get is unpredictable from one instance to another.
We want a clinically meaningful demo dataset that can be installed quickly and is the same every time you create it (so, for example, users can rely on particular patients are data being there when doing demonstrations, etc.).
Filip Biedrzycki already did some work on this ticket, to change the random generation of patient data to instead be deterministic. The remaining work is about speeding things up by creating the demo patients at build-time instead of on every client.
- The maven build of the standalone builds a standalone that works, and includes zipped mysql database files (emptydatabase.zip and demodatabase.zip). But these databases have not yet had reference application module activators run on them. So the first time a user starts the standalone, it has to do a lot of work, which is a very bad user experience. It is okay for snapshot/nightly builds to behave this way, but we need to do better with releases.
- We need to improve the bamboo build in ci.openmrs.org in the REFAPP-OMODDISTRO plan, so that there is a manual step/stage that does more expensive work up front to package a standalone whose zipped database are ready-to-go.
- Ideally this would be done as part of the standalone maven build, by running the OpenMRS API with the appropriate reference application modules, waiting for it to start, killing it, and taking a database dump. This is probably too much work to do in the available time.
- Easier alternative is to script this from bamboo:
- run the standalone we built in an earlier step/stage
- wait for all activators to run and OpenMRS to start up. (This requires adding a feature to OpenMRS core so you know when this happens. Suggestion: a servlet named "up" outside of openmrs-servlet so it can still return immediately while the context is refreshing)
- stop the standalone
- zip the current state of the database, and make this available as a build artifact (someone will manually download this to assemble the standalone for release)
- To do the above, depending on your level of skill with different technologies, it may be easiest to (a) script this all in bamboo, or else to (b) add functionality to the standalone such that if you start it up with a certain command-line argument, it starts OpenMRS, waits for startup to complete, zips the database into an output folder, and shuts itself down
- Any changes need to be made to the openmrs-emr branch of openmrs-standalone.
It is a nice-to-have if across our different releases we get the same demo patients. Investigate whether we can use a known/fixed seed to the random number generator. (The most useful thing would be if we always get the same 100 patient names in the demo dataset, so if you're used to searching for "Christian" in 2.1 demo data, you can also find "Christian" in 2.2's demo data.)