Scala Object Serialization for MapR-DB by Nicolas A Perez

Let's take a look at things from a Scala point of view!

If you're using MapR-DB it is common to serialize and deserialize objects to JSON as MapR-DB data is stored using JSON format. Have a read of this article by Software Engineer, Nicolas A Perez on the steps of this process.

Previously, we have discussed some of the advantages and features accompanying MapR-DB. However, this time we are going to get our hand dirty while using this enterprise-grade database.

When using MapR-DB, it is a common practice to serialize and deserialize our business objects (commonly known as POJO) from/to JSON all the time since MapR-DB data is stored using JSON format. These operations are very common and frequent so we will take a look at them from Scala’s point of view.

MapR-DB Document API

There are a series of steps to be followed to create new objects and to insert them into MapR-DB. Let’s look at the typical workflow.

This is the basic steps to insert into MapR-DB. This snippet can be extended for more complex use cases, but essentially, they will look very similar to this one.

There is one issue that can be easily recognized here. The way we create the 'document' object through the fluent API is far from convenient. Normally, we would like to pass a POJO instead of building the document manually.

If you try this out, you will discover that the object 'link' cannot be converted to Java Bean because of the value '_id' starts with '_'. This might look small, but all documents inserted to MapR-DB should have the field '_id', converting this initial, small issue into a deal breaker.

We can always go back to use manual object construction for each POJO object we have, but we should walk away from this idea as soon it comes to us, for obvious reasons.

Another alternative is to look at mechanisms to convert Scala objects to Document. It is evident we need a type class for doing the heavy lifting and bring flexibility to the conversion system.

Let’s define a type class for doing this work. Let’s name it 'MySerializer' for a lack of a better name.

As we can see, 'MySerializer' uses a default way to convert objects to document using Jackson serialization. Having a default serializer is a good option since the majority of the objects will use it, yet not everyone is built the same, so we need specializations as well.

As mentioned before, sometimes the default document conversion won’t work, for instance, let’s look at the following example.

1 case class Person(name: String)

Using the default converter with 'Person' will cause an error when trying to save the generated document to the database. MapR-DB needs an '_id' as the document key as stated before. In this case, we need to a custom converter for the class 'Person'.

This is where the type class mechanism shines. We can specify the exact way to create documents from Person. Let’s see how.

Notice that we have both options, one is to use the default serializer and the second is to use a custom serializer to the specific object in question. This allows a fine-grained serialization mechanism that ultimately yields genericity without given specialization up.

At the same time, the serialization system is outside of the object itself. We should be able to modify how the serialization works without affecting the objects at all. Ultimately, we could override how serialization is done based on a specific context while having different serialization mechanics for different situations as they are needed. This is almost impossible to do in Java, but Scala is a beast at the Ad-Hoc polymorphism world.

Conclusions

MapR-DB OJAI API is nice, but it does not play well with Scala objects, especially around those that do not comply with the Java Bean specifications. On the other hand, Scala offers advanced constructs like type classes that allow us to go around many of the interoperability issues out there while keeping type safety and enabling ad-hoc polymorphism.​'

Archive

Signify Technology is an innovative technology recruitment business with offices based in London & Los Angeles. We provide permanent and contract technology recruitment solutions to a wide range of the world's leading brands on a global basis including blue chip, technology companies and start-ups. Behind each piece of technology changing the world, is a person, it's our mission to introduce them to the companies that need them the most.