Feature Release of Morphium V2.2.9

veröffentlicht am : So, 28. 09. 2014 geändert am: So, 28. 09. 2014


ATTENTION: This version does not run properly in Tomcat or Jetty environment. We're working on a workaround...

New feature release of morphium 2.2.9. Available on github and via maven repository...

This version introduces type_ids. this is useful, if you want to be able to change Classnames and or refactor your code later (e.g. change packages etc.).

public class MyEntity {


Usually morphium determins the name of the type from the query given. But when it comes to subdocuments and arrays or embedded maps, morphium needs to store the type information in mongo in order to be able to unmarshall the object.

Usually morphium uses the classname for this (which is the default type_id), but this breaks deserialization of objects, if class names or packages change. Every time you refactor something, you need to be sure that you do not break things.

Introducing type_ids solves this problem. It's recommended to use type ids for all of your Entities to be able to change your code as you like.

One additional info: If you change your classname, the default collection name will also change. So, to be able to do all refactorings you should define both a type id and a collection name:

@Entity(type_id="PersonEntity1", collection_name="persons"
public class MyInternalPersonRepresentation {


Attention: This feature makes it necessary, that morphium scans the classpath for entities and their type ids. If this causes problems on your setup, please let me know! (it only tested on MacOS X and linux for now). This might also slow down startup a bit (depending on your classpath)...

Migration to type ids

I was asked by a couple of users of morphium, how they could migrate to those new type IDs. you need to know, that you don't need to migrate at all if your java entities handled by morphium is not refactored. Morphium 2.2.9 is totally backward compatible with your data and you can safely upgrade anytime. But if you plan refactorings, it's not that hard to migrate:

Before doing the refactorings, run though all your data, that might have lists or maps containing entities, and add the corresponding type_id. This is type specific, of course.

You could also solve that iteratively by registering a MorphiumStorageListener either for a specific type (or types), or for all storage operations. Again this is very type dependent: some types do not need a change, some contain lists or maps, that need to be updated. (and you'd need to access mongo directly using morphium.getDatabase())

After you have prepared your database, you can update your codebase.

erstellt Stephan Bösebeck (stephan)