MapR-DB的Scala对象序列化

P reviously，我们已经讨论了一些优势和特点伴随MAPR-DB。 但是，这一次，我们将在使用此企业级数据库时动手操作。

使用MapR-DB时，由于MapR-DB数据是使用JSON格式存储的，因此通常始终将JSON中的业务对象（通常称为POJO）从JSON序列化和反序列化。 这些操作非常常见且频繁，因此我们将从Scala的角度对其进行研究。

MapR-DB文件API

创建新对象并将其插入MapR-DB需要遵循一系列步骤。 让我们看一下典型的工作流程。

这是插入MapR-DB的基本步骤。 可以针对更复杂的用例扩展此代码段，但是从本质上讲，它们看起来与此非常相似。

这里有一个很容易识别的问题。 我们通过流畅的API创建document对象的方式远非方便。 通常，我们希望传递POJO而不是手动构建文档。

在Java中，我们可以执行以下操作。

在上面的代码中，我们可以看到我们的Link类用于创建将保存到数据库的文档。 MapR-DB将利用Java Beam对象创建文档对象。

现在，使用Scala时，问题变得更加乏味，无论如何，这应该是您的选择语言。

Scala问题

使用Scala，我们还可以像Java中一样使用Java Bean创建所需的对象，但是很快就会出现其他问题。 让我们看一下之前使用的相同示例，但是这次是在Scala中。

如果您尝试此操作，则会发现由于值_id以_开头，因此无法将对象link转换为Java Bean。 这可能看起来很小，但是插入到MapR-DB的所有文档都应具有_id字段，以将最初的小问题转换为交易破坏者。

我们总是可以回过头来为每个POJO对象使用手动对象构造，但是出于明显的原因，我们应该尽快放弃这种想法。

另一种选择是查看将Scala对象转换为Document的机制。 显然，我们需要一个类型类来完成繁重的工作并为转换系统带来灵活性。

让我们定义一个用于完成这项工作的类型类。 由于缺少更好的名称，因此将其命名为MySerializer 。

如我们所见， MySerializer使用默认方式使用Jackson序列化将对象转换为文档。 拥有默认的序列化器是一个不错的选择，因为大多数对象都将使用它，但是并不是每个人都构建相同的，因此我们也需要专门化。

现在，我们的代码将如下所示。

如前所述，有时默认的文档转换无效，例如，让我们看下面的示例。

在尝试将生成的文档保存到数据库时，将默认转换器与Person将导致错误。 如上所述，MapR-DB需要_id作为文档密钥。 在这种情况下，我们需要为Person类创建一个自定义转换器。

这就是类型类机制的亮点。 我们可以指定从Person创建文档的确切方法。 让我们看看如何。

请注意，我们有两个选择，一个是使用默认的序列化器，第二个是对有问题的特定对象使用定制的序列化器。 这提供了一种细粒度的序列化机制，该机制最终会产生通用性，而无需进行专门化。

同时，序列化系统在对象本身之外。 我们应该能够修改序列化的工作方式而根本不影响对象。 最终，我们可以根据特定的上下文覆盖序列化的完成方式，同时针对不同的情况根据需要使用不同的序列化机制。 这在Java中几乎是不可能做到的，但是Scala是Ad-Hoc多态世界中的野兽。

结论

MapR-DB OJAI API很好，但是它不能与Scala对象一起使用，特别是在那些不符合Java Bean规范的对象周围。 另一方面，Scala提供了诸如类型类之类的高级构造，使我们能够解决许多互操作性问题，同时保持类型安全性并启用即席多态性。

感谢 Lombok Project 帮助我们编写了更简洁的Java代码。

感谢S imulacrum 在没有样板的情况下在Scala中启用类型类。

From: https://hackernoon.com/scala-object-serialization-for-mapr-db-792817d3962d