Morphia - change class associated with a collection

Question

I'm trying to phase out an older java codebase that uses MongoDB/Morphia. During this transition, I'd like the new platform to write to the same MongoDB database/collections so that each can live side by side for a little while. That part I'm doing alright with. My issue is that in the new platform, I need a different package/class structure for the objects I'm mapping with morphia than what is currently in the collection.

For instance, in the old platform I've got this class:

package com.foo;

@Entity
public class Bar {
    @Id private String id;
    private String name;
    ...
}

In my mongo database, I now have a collection "Bar" and its documents have the className attribute set to "com.foo.Bar". That's all wonderful.

What I'd like to do in the new platform is create a brand new class in a different package to represent that entity, but have it interact with mongo in the same way. I'm hoping to be able to do something like this:

package com.foo.legacy;

@Entity("com.foo.Bar")
public class LegacyBar {
    @Id private String id;
    private String name;
    ...
}

I realize the above doesn't work, but if I change the annotation to @Entity("Bar") I don't get any errors, but when I look up entities by id, I always get null back.

So... is there any way for me to have 2 separate VMs with 2 class structures and 2 different configurations of Morpha such that each can write to the same database/collection in the same fashion?

If I change LegacyBar to just "Bar" and create it in a package called "com.foo" then everything works as expected. I would just REALLY prefer to have the flexibility to quarantine all of this legacy data in a semi-clean fashion.

Answer 1

Do you even need the className attribute?

You can disable it with

@Entity(value = "Bar", noClassnameStored = true)

and drop the attribute in the database.

Quoting the official documentation:

Why would you need it? This is mainly used when storing different entities in the same collection and reading them back as the base or super class.

If you don't do this, it should be an easy workaround to allow different package structures.