So what you are referring to is the documentation here, and possibly then a little clarification of what that means along with the opinions that are offered in that document.
So as the document says, as per your quote, is that the index definitions you provide for your "Entity" classes are picked up by the .ensureIndex()
method on the datastore, "when that is called in order to go and "re-create" all of those indexes.
The second point in the documentation defines this "as an example" along with the class mapping definitions like so:
Morphia m = ...
Datastore ds = ...
m.map(Product.class);
ds.ensureIndexes(); //creates all defined with @Indexed
And indeed that will be invoked every time your application is started, and some consider this best practice to ensure that all the definitions are "up to date" as it were. But also note, this is only an opinion.
As you seem to be pointing at, it would probably be better practice if you simply had some "post deploy" hook in which can be called when you actually "deploy" your application, or indeed "as needed" where you determine that re-defining your indexes is actually required.
It is generally one technique that I agree with, is to expose such a method as "callable" API for your application so that upon deployment, you can "script in" methods there to call that API function and actually re-define all your indexes (or even sub-set of) as you decide to do so.
So the actual interpretation is that using Morphia does not actually mean your indexes are re-defined every time the application is started "automatically", but if you do put the call to that .enssureIndexes()
method somewhere where it will be called every time the application is started, then it will do so.
Don't call this in the same place as the class mappings. Put it somewhere else where you can control this, and the problem is solved.