Why is annotating mappable classes necessary?

[bendherville]

We are migrating from morphia 1.x to 2.4 and having to add annotations to all of our classes that are used as top-level or embedded types (there are lots of them). Not complaining about doing work :) but the question is why is this necessary in v2.4? Can't it be assumed that a type being persisted is mappable and use the same defaults as applied to classes annotated with @Entity?

[evanchooly]

With lazy evaluation of the mapping, having no mapping information isn't necessarily a problem. (Though it has resulted in the odd bug over the years.) But morphia is taking a more forward looking, proactive view as time passes where knowing the mapped entities makes mapping both easier to implement and more performant for users. In 3.x, this mapping is likely to happen more at build time than runtime so knowing which types are of interest is paramount at that point.

[bendherville]

I understand and agree with the benefits you mention, however, preventing implicit mapping reduces ease of use when users need to store any object in the database which is a major drawcard of a document DB.

From looking at the morphia 2.4 code it seems feasible to allow dynamic, runtime mapping registration for unannotated entities. So I'm suggesting that it would be helpful to some if there was a configuration option to allow it. Perhaps it's disabled by default with a documentation warning stating the performance and clarity impacts.

[evanchooly]

The optimizations that can be done with explicit annotations would be undone by supporting an opt-out option. It would introduce other complexities in mapping that have lead to subtle bugs over the years. And it would still run afoul of corner cases of features like external entities that would be unnecessarily complicated to handle. I do try to avoid creating more work for users just to make my life easier but in this particular case it's both simpler for me and more consistent and stable for users.

[bendherville]

I'm currently in the depths of dealing with this issue now and have found several issues;

1. There are hundreds of classes which we embed in other entities that come from external libraries. It's virtually impossible to determine all the classes so that we can create ExternalEntity mixins for them.
2. MixIns appear to be flawed in version 2.4.13. If I define a MixIn for a class I currently have to redefine every field in the MixIn because the target class is not considered when the property models are discovered.
3. As an interim workaround to the above issues I planned on subclassing MorphiaCodecProvider so that I could dynamically add the @entity annotation to types (using bytebuddy) when trying to map types at runtime. However, there is no way to add/replace the default MorphiaCodecProvider because;
   a. DatasourceImpl.buildRegistry is private
   b. DatasourceImpl.importModels discovers EntityModelImporter implementations but the EntityModelImporter constructor accepts Mapper instead of Datastore which is required to create a MorphiaCodecProvider. Therefore EntityModelImporter is completely broken.
   c. Morphia config has morphia.codec-provider which can be used to provide a provider but that must have a default constructor and therefore I can't have a provider that extends MorphiaCodecProvider which requires a Datastore.

As far as I can see I have these options to move forward;

1. Submit PR so morphia allows me to override the default MorphiaCodecProvider
2. Use instrumentation to modify the MorphiaCodecProvider
3. Fork morphia and make changes

Would appreciate any suggestions?

[bendherville]

As per Option 1., this PR #3037 would be enough for me to workaround the issue in the short term