Upgrading OpenMRS 2.0 modules to support Hibernate 4

Development
1

OpenMRS 2.0 modules have to be upgraded to support Hibernate 4.

A good way to achieve this whiles maintaining (backward) compatibility with Hibernate 3 is discussed on this wiki-page. https://wiki.openmrs.org/display/docs/Supporting+Platform+2.0+and+below

A consensus is needed on how best to manage this upgrade requirement, such as using the reflection approach to support both Hibernate 3 & 4.

Any comments on whether this reflection approach is the right approach?

1 Like
2

If thereā€™s no alternative and as a temporary solution itā€™s acceptable. Using exceptions to control flow is an anti-pattern :slight_smile:

3

Further research has indicated the following.

The hibernate 4 sessionfactory class is different from the hibernate 3 sessionfactory class. The applicationContext of OpenMRS versions which have to support hibernate 4 can use the new configuration. ie

Any module building against the right OpenMRS version will get the right hibernate sessionfactory which have the same interface.

There seems to be some differences with the way transactions are handled between the two versions, however the behavior is (should) be equivalent if a JTA is configured. If OpenMRS does not configure a JTA then more research is needed.

4

Last time we discussed this, the consensus recommendation was:

  1. Our recommendation is that most modules should: (1) increase their required-version of OpenMRS (i.e. to at least 1.11.3, 1.10.2, 1.9.9) and (2) start using DbSessionFactory where they used to use SessionFactory.
  2. In some special cases you can take the alternate approach that XForms did.

This is documented here: https://wiki.openmrs.org/x/uoMgBQ

Has anything changed since then?

Generally speaking, ā€œupgrade to the latest version of your release lineā€ should be expected behavior of any implementation that wants to upgrade their modules. And the OpenMRS collective should behave as if itā€™s expected, and not constantly second-guess ourselves.

5

Option 1) works fine.

I am investigating an approach which is in line with option 1), ie. modules have to update their required version of OpenMRS.

It seems that the sessionFactory bean configuration in applicationContext can be changed to support either Hibernate 3 or 4. So each version of OpenMRS can use the appropriate version of the hibernate sessionFactory config depending on the hibernate version it supports.

If tests bear this out, then the modules will just have to build to the version of OpenMRS (& hibernate) without any changes. This also does away with the need for the DbSessionFactory wrapper.

I will update this discussion with test results as soon as I have them.

6

There is need for guidance on this task, regarding webservices.rest.

webservices.rest is actually built to support platform versions 1.8, 1.9,1.10, 1.11 and now 2.0. The various versions builds on earlier versions, so 1.9 depends on 1.8 etc.

Note because of platform differences it does not seem possible to build webservices.rest-omod-1.8 against openmrs-1.10 for example.

How do I support both DbSessionFactory and SessionFactory in one module side-by-side, ie what is the best way to solve this problem?

7

How about bumping the versions to the latest maintenance versions of each release line that has DbSessionFactory? You could back port DbSessionFactory to 1.8.x in order to take care of the 1.8.x line.

8

I think we should drop support for 1.8.x, and increase the versions of the supported release lines to 1.11.3, 1.10.2, and 1.9.9.

I would leave all the omod-1.8 stuff where it is, just start building that against 1.9.9.

1 Like