To address various issues in older APIs, some new packages were introduced under an
experimental subpackage. These packages have had
sufficient time to bake and are being promoted out of experimental status in 2.3. Unfortunately, there isn’t a feasible, non-breaking
way to do this so upgrading to 2.3 is a mild breaking change. The good news is that these breaks can be fixed by doing a global
.experimental. This should fix all the cases where Morphia has promoted these packages.
There are, however, two options being provided that might help with this process. As always, make sure to commit any of your changes before using an external tool to mass update your code. And, of course, examine the changes afterward to ensure no breakages.
The first tool is openrewrite. This is a powerful, general purpose tool for updates and migrations of
all sorts. In our case, it’s primarily just removing the
experimental segment out of a few packages. To use this script, download the
script and save it as
rewrite.yml in the root of
your project. Once that is done, run the following command:
mvn org.openrewrite.maven:rewrite-maven-plugin:4.37.0:runNoFork -DactiveRecipes=dev.morphia.UpgradeFrom22to23
This script will update the packages to reflect their new names. It will also update your pom to the latest Morphia version for you if that has not been updated yet.
Alternately, if you have jbang installed, you can run a script to do this work for you. It’s a little more brute force than the openrewrite approach (it’s literally just doing string replacements) but might be necessary in some cases. If you’re a kotlin user, you’ll want to use this approach as openrewrite does not currently support kotlin source files. To run this script, use the following command:
You will likely be asked to specify the level of trust you have for this script and the MorphiaOrg github organization. Choose whichever level you’re comfortable with.
Whichever path you choose, even if that’s manually doing the updates yourself, make sure to examine the diffs and run your tests to make sure nothing was broken. Though these approaches have both been tested on a number of projects, user code and project structures can be wildly different and some unhandled corner cases might arise.
In the future such "experimental" items, the ones that need a little time to "bake" and get real world usage and feedback, will be marked
As part of the modernization of mapping configuration introduced in 2.0, a
legacy() option was added to
MapperOptions to preconfigure
the mapping options to reflect the pre-2.0 configuration style. Part of the modernization of 2.0 also included how querying is done.
legacy() method mentioned above also configured this legacy querying style. As of 3.0, this
legacy() option, and the querying
API associated with it, will go away.
However, it will still be possible to configure your application with the old settings, you will just have to be explicit about it. To
update to this new configuration approach, rather than using
MappingOptions.legacy().build() as you have perhaps been doing, simply
replace it with something like the following:
MapperOptions.builder() .discriminatorKey("className") .discriminator(DiscriminatorFunction.className()) .collectionNaming(NamingStrategy.identity()) .propertyNaming(NamingStrategy.identity())
This will preserve the older mappings used by your data while enabling the modern query API implementation. Some users will have date/time data stored under an older storage scheme. Those users will also want to include the following option:
Versioned updates now throw
VersionMismatchException instead of
This allows for more targeted catches.
For historical reasons, this new exception extends
ConcurrentModification so that any existing catch clauses will continue to work.
However, applications should be updated to catch the new exception.
A future release will change the parent type of
See this discussion for more details.
Kotlin classes have worked with Morphia for years now but certain Kotlin features have started to cause problems as folks have started trying to use them in their applications.
To this end a new module has been introduced,
morphia-kotlin, to specifically focus on these cases.
Chances are good that you won’t need this module but in some cases this new module can help.
reference guide for more details.