Sure thing, I will continue the discussion on the JIRA issue.
Since @michael helpfully reminded us we shouldn’t have substantive conversations in the issue tracker, we seem to have lost the thread…
So, what do you think about how to approach this.
I can try to modify the base test classes to allow using a database other than H2, depending for instance of a system property (now is hardcoded to use the in-memory one). But IMHO this should be out of the scope of MariaDB testing. This doesn’t mean that I don’t want to do it, but it won’t be a couple of hours.
A better way to test MariaDB is to update the wiki suggesting new developers to use it instead of MySQL, and issues will arise fast.
@lluismf, definitely asking all new devs to use MariaDB instead of MySQL would solve some problem, but I think our real goal is to grow to the point where we support multiple databases, not just (a different) one.
Are you interested in working with @cintiadr to figure out how to achieve that, through some use of testing and CI?
Yes I do, it’s only that I don’t have much time to spend.
I don’t have heaps of time this week or the next, but after 18th I should be much more free.
What I’ve done is installing docker on the agents. https://ci.openmrs.org/browse/RELEASE-MDT-6/log
I have this pretty simple build starting mariadb and kill it at the end. Is there any super simple way to test importing data? Any arbitrary username/password can be passed.
Newest version of Bamboo has a nicer support to docker, we can upgrade Bamboo those tests work.
I don’t think we need to import any data. The idea is to run the tests against an empty database and let the tests insert the initial data. It’s already done for the in-memory DB, it just needs to be tweaked to connect to a “normal” database.
Is there anyway I can test that?
Because after running docker container (and waiting a little bit), we’d have an empty database.
So I’d like to set up a build which starts database, import data and run the tests - but I have no idea how it’s done for OpenMRS. If you could give me hints and tips, I guess I could find my way.
Currently the only way to not use the in-memory database H2 is to manually change the code (specifically make BaseContextSensitiveTest.useInMemoryDatabase to return false). This is not very practical. My proposal is to make it possible to change this behaviour externally by means of environment variables. The process will be as follows:
Check existence of openmrs.test.useInMemoryDatabase If not exists or is true Then connect to H2 database Else read environment variables - openmrs.test.connectionstring - openmrs.test.user - openmrs.test.pwd connect to external database End
Delete all tables (*) Insert initial data
(*) deactivating the FKs uses non standard SQL commands, maybe I’ll need to add the db dialect also to the env vars
I agree, we need to make opting out of using the in-memory DB configurable externally
@cintiadr, have you gotten what you need to move this forward? Or could you use help (information and/or some peoples’ time)?
@lluismf, @wyclif – do we have a ticket to make our tests use a database specified in an environment variable (i.e., allow environment variable(s) to optionally specify a db connection other than H2)?
@michael, @ryan – what would it take to get Bamboo updated to latest (5.9)? Atlassian has been adding some nice docker features in the past couple versions that would help @cintiadr move forward with mariadb-based builds.
It should just be a matter of scheduling some maintenance time for bamboo. Either @cintiadr or I will want to try out the upgrade in staging just to make sure everything goes smoothly.
I have created this issue to add support for setting test database credentials externally:
The docker tasks in Bamboo is a nice wrapper for the docker command, but it doesn’t add any new functionality to it.
(Well, it can wait for a URL to be available, but I don’t think there’s anything else).
Of course, it’s nice, but it doesn’t change how to handle the container.
We set a goal of supporting MariaDB by this September’s OpenMRS 2.3 release. “Supporting MariaDB” means our builds fail when our code doesn’t run on MariaDB as well as MySQL.
Do you think this goal is attainable with the time & effort you all have between now and September?
- Do you think we need to seek additional volunteers to meet that goal?
- Are there specific tasks we should solicit help with to reach our goal?
- Are there specific blockers we could help eliminate?
- Other thoughts/concerns?
I appreciate the contributions you’ve already made and want to help build on those efforts to get the community to sustainable builds against MariaDB.
I use mariadb on my linux system, and I’ve been using it for my GSoC project too. So I guess more hands always do lighter work. The more volunteers we can have for these tests the better an appraisal we can get and easily fix most of the issues associated. I’ve not started running it on the most current release. But I’ll try to test it on Fedora and see how it goes. But I guess with more volunteers this can easily be done by September to support to next release for OpenMRS.
Next week I’m on vacation but in august I’m free, I’ll try to help with the test class.
September looks distant enough
But I need someone willing to setup the build, setup a instance using jetty:run or similar on the agent with the mariadb docker container. I still have no idea how to do that, how to start OpenMRS and configure it to use an specific database.
Is there anyway to configure it by a file? Or how to populate the data.