Voyage: Persisting Objects in Document Databases
A Simple Tutorial with Super Heroes
This chapter describes a step by step tutorial showing the possibilities offered by Voyage (an object to document mapper) We will use a simple but not trivial domain: super heroes, super powers and their equipments. You will learn how to save and retrieve objects.
Creating a connection
One you installed MongoBD, we can start to connect to the database as follows:
If you are not connected to a database, you can always use in memoryrepository (useful for prototyping your application).
With this approach you can work as if you would be connected to a real database and later during your development you will be able to transparently switch mode.
Usually we define one single method to set up the repository.
For example, we can add a class method to the class Hero
that we will define just after.
SuperHeroes
Now we can define a first version of our domain. Figure shows the model that we will use for this tutorial.
Heroes
Let us define the class Hero
.
... and Powers
Let us define the class Power
.
Ajoutez les méthodes printOn:
afin d'améliorer la navigation et le débuggage de vos super heroes.
Root classes
Now we have to decide what are the objects that we want to save and query. For this we should declare
the roots of the object graph that we want to save. A root can be any class of the system. Declaring a root is done by implementing the class method isVoyageRoot
on the class of the objects that we want to save. We will see the implications of defining a root later. For now we just define Hero
as root.
We can create some superheroes and save them in the database.
Checking in MongoDB
We can check directly in the database to see how our objects are saved.
Now we can see how a superhero is actually stored.
db.Hero.find()[0]
gets the first object of the collection.
Note the way the powers are saved: they are embedded inside the document that represents the superhero.
Queries
Now from Pharo, we can perform some queries to get objects stored in the database.
Since MongoDB is storing internally JSON, the argument of a query can be a dictionary as follows:
Here is a more complex query:
Other Basic Operations
Here are some simple operations that can be performed on root classes.
Counting
First we show how we can count:
Removing
We can remove objects from the database.
We can also remove all the objects from the class.
Adding a new root
Now we will change our requirement and show that we want to be able to query another class of objects: the powers. Note that when you add a root, it is important that you either flush your database or perform a migration by for example loading old objects are republishing them.
Each time you change the database 'schema', you should reset the database using the following expression:
When to add a new root
There are two main points to consider when facing the questions of the necessity of adding a class as a root.
- First, the obvious consideration is whether we need to query objects separately from their objects that refer to them.
- Second, if you need to make sure that subparts will be shared and not duplicated you should declare the subparts as root. For example if you need to be able to share a power between two super heroes and want to be sure that when you load the two superheroes you do not get two copies of the same power.
Power as a root
We declare Power
as a new root.
Now we can save the super power objects separately as follows:
If you do not see the new collection in the database using show collections
you may face a Voyage bug and you need to reset the memory database cache in the Pharo image doing:
Now saving your objects and checking the mongo db again should show
Now we can save a hero and its superpowers. To fully test we flush the heroes in the database
executing Hero removeAll
and we execute the following:
Note that while we saved the powers independently from the hero, this is not mandatory since saving a hero will automatically save its powers.
Now when we query the database we can see that an hero has references to another collection of Powers and that the powers are not nested inside the hero documents.
About relations
Voyage supports cyclic references between root objects but it does not support cyclic references to embedded objects. We will see that in the following section.
Extending the Hero class
We will now extend the class Hero
with equipments. This example shows that the root collection declaration is static: when a superclass is defined as root, the collection in the mongo db will contain instances of both the class and its subclasses. If we want to have a collection per subclass we have to define each of them as root and you should duplicate the isVoyageRoot
method in each class.
We add a new instance variable named equipment
to the class Hero
.
Since we change the class structure we should reset the local cache of the database doing VORepository current reset
.
Now we define the class Equipment
as a new root.
And we define two subclasses for Weapon
and Armor
Now saving a new hero with equipment will also save its equipment as a separate object.
We can see how the objects are saved in the database
Since we did not define Weapon
and Armor
has separate roots, there is only one collection named Equipment in the
database containing both weapons and armors.
Equipment can also have powers
In fact equipments can also have powers (like the hammer of Thor). Therefore we add powers to the equipments as follows:
Since we change the class structure we should reset the local cache of the database doing
And we can now add a equipment with powers to Ironman as follows:
We see in the database that the Equipment collection contains Armor objects.
Note that an equipment could contain an equipment. To express this we do not have anything to handle cyclic references since the class Equipment
is a collection root.
Conclusion
This little tutorial shows how easy it is to store objects in a Mongo database. It complements the space of possible solutions such as using Fuel to serialize object, using the in-memory SandStone approach or the more traditional relation database mapping with Garage.