Should I create the databases beforehand...
I think so.
In my opinion, database settings, users, grants and some of the index should be DB scripts that we can execute anywhere and anytime to re-create or fix the database. My reasons to believe it are two.
- First, the user creating and setting up the DB has too many privileges as for us to set it as the default application's DB user.
- Second, we don't need to deploy the application to prepare the persistence layer.
Another reason can be testing. If you are not familiar with MongoDB, it's likely sooner than later you will want to test if your document structures are compatible with your querying needs. In my very first Spring Boot - MongoDB application I spent a lot of time on
- Getting familiar with Mongo's DSL
- Finding out the MongoDB query I needed. Usually the hard ones.
- Validating the adequacy of the document structure
- Translating the scripts into Spring Data notation.
- Validating Spring Data Mongo was compatible.
The last point is very important. Newer versions of MongoDB might or might not be fully supported by Spring Data. Every time you updates the MongoDB, you must do the same with Spring Data MongoDB and ensure it's fully compatible with the new features. And backwards compatible too!!
I did mention Indexes too. Well, you will find Spring's TextIndex support to be a bit limiting and very very conditioned by the class hierarchy or its composition. For the sake of the answer, I won't go deep into details, so just try to make a class addressed to model multilanguage text fields, set entities with two or more of these fields and then try to make text searches sorted/filtered by text score.
You will find that some of these shortcomings are addressable programmatically, but I have found the code to be hard to defend. It's cleaner and simpler to have these workarounds in scripts files. The same way you would on MySQL. Note that failures at this point will prevent the Spring Boot application from bootstrapping. Once the mess is done, you will need to sort the issue directly from the DB... So better to have these scripts at hand.
If so, should I have manual scripts for this (e.g. db.createCollection(), ...)?
Yes. Note that collections can be configured to behave differently depending on their needs. The name is the first property of any collection, but not the last or the only. I don't recall if @Document allows you so fine-grained level of configuration, but even if so, I don't see why this meta-data should be declared in the source code. In relational databases, we usually set all these things by SQL scripts. No reason to make it different on MongoDB.
Should I use a migration tool (e.g. mongobee), or is it a "less common" approach when working with Mongo?
We can't say. It depends entirely on the needs. I can say I do use Mongeez for very specific changes on the DB, those I need to execute once and only once with each new version. Other than that I make scripts which I execute from a console. The reason is obvious, I don't want to be forced to deploy the application in N different environments just to fix a problem I can solve executing a script from a console. Customers are reluctant to perform unscheduled deployments or halting PRO unnecessarily.
If it's uncommon or not, I don't know. I guess it's as (un)common as on RDMDBs.
