Deprecate alternate collection saves

[evanchooly]

Currently, it is possible to save an entity to a collection other than what is mapped. This feature does not appear to be widely used (or known!) and causes innumerable complexity when loading, say, references. This misfeature will be deprecated in place of separate, explicit entity types.

[arunbenoyv]

@evanchooly Hi We are using this feature widely in production. We have recently upgraded to 1.5.5 and could see that it was deprecated. Is there any alternative approach in 2.0.
We were using this feature to support dynamic collections based on same Entity for different services.

[evanchooly]

The "problem" has several facets to it. I've never liked how that's been handled by what I'll call the legacy API. (In my head i'm already on 2.0. :D ) Certain features supported ad hoc collection mapping (saves, updates) while others no only didn't but couldn't for $reasons (references being the primary one here).

There are examples of multitenancy out there that I'm looking to for inspiration on how to handle it in morphia. JPA is the biggest example I'm looking at. JPA does not support ad hoc entity saves that I've been able to determine. (it's been easily 7 or 8 years since I've used it in anger.) I'm exploring how they offer multitenancy with an eye on how to do it with Morphia in a way that's consistent with standard OD/RM behavior that doesn't require contorting the API to make it work.

In the case of references, 1.5 introduces an experimental approach to defining references. Instead of using @Reference, you'd declare your field to be MorphiaReference<Foo>. You'd create these references using MorphiaReference.wrap(foo) and you'd get back the appropriate wrapper that handles single references, list (List<Foo>), sets (Set<Foo>), and maps (Map<String, Foo>). It's conceivable that one could overload wrap() to take a collection name as well. This comes with the limitation of all references being wrapped are stored in the same collection. This is not too far off of the implicit requirement today in Morphia but it is worth noting.

Additionally, the API in 2.0 has evolved to a much more fluent API and the overloads to support the various options were breaking down as the options grew. As such, adding back in an override to support the ad hoc collection has various aesthetic and technical issues. This fluent API as moved most/all of the options to an explicit options class to be passed in at the terminal method (save() or execute() in the cases of find/update, e.g.). The ad hoc collection name could be passed as an option on the options parameter and would preserve the cleanliness in the API that 2.0 is striving for.

I'm not sure how best to approach multitenancy in Morphia. Allowing ad hoc collections has led to complications in the API and I'm hesitant to reintroduce them to the new mapping scheme. But these are some thoughts off the top of my head that might be a palatable compromise. How does any of this sound to you? What is the use case you're trying to support?

[DefiantCatgirl]

I'm also moving objects of the same class between collections, e.g. for archival/search/optimizations, and it would certainly be very convenient to have a one-liner rather than inheriting different classes from the same base class and manually copying objects. An option e.g. at the save() method would certainly be very helpful, AdvancedDatastore's save() in 1.* was quite similar and convenient in that respect.