0

I want to have some opinions on how to handle the scenarios where domain model changes post serialization. Like in out project we save the pojos in a XML format in a Marklogic database. It is a kind of recovery store for us.

But there are chances that we might some change in our pojo model, i.e. some hierarchy changes for field level changes. So if i will try to recover from our DB. It will break.

So how do i handle such situations ??

Ambuj Jauhari
  • 1,187
  • 4
  • 26
  • 46

3 Answers3

3

One way of looking at your question is that it is an application/Java level question entirely. Pretend for a moment that a database is not involved, how does your application intend to manage coexistence of 2 data models ? 'DTO's or Object/Object mapping is one way of handling this. E.g. using libraries like http://mapstruct.org/ http://dozer.sourceforge.net/ https://github.com/FasterXML/jackson - you can define mappings between versions of POJOs and transform them at runtime. This solves the problem as asked, but misses out on the potential of MarkLogic as more than a simple POJO store.

Another way of looking at this, similar to Johns answer, is that using MarkLogic in the fashion you describe (simply as a way to serialize POJOs) is not making efficient use of its capabilities. MarkLogic is both an application server and a database in one. By using a small amount of server side code, you can implement a stable interface that can support various formats and evolve with your app. This also lets you 'offload' processing to the server which can often achieve significant performance improvements. There is no need for the data format stored in the server to resemble in any way the format sent or received by the app.

This is particularly true when you do operations that require more than one 'object' at the application layer - If you use the traditional RDB ORM (Object Relational Mapping) model with MarkLogic and make a 1:1 mapping of POJO to Document you miss the opportunity to combine and refactor operation on the server and often have to make many requests to perform what could be done in one. Not only is there the overhead of multiple requests but many operations in ML are significantly more efficient when not constrained to having to store DB objects modeled 1:1 with the application objects.

If you move the interface to ML up layer or more in your application you can perform business logic on the server instead of the client, and instead of storing the lowest level POJO's on the server, instead implement a 'service' model. This often results in significant performance improvements reduced code size.

DALDEI
  • 3,722
  • 13
  • 9
1

MarkLogic is essentially a schemaless NoSQL store, which means that trying to force a schema on it and expect it to never change (like a concrete POJO model) is going to defeat the idea. If you want to remain flexible and allow for schema modifications over time, I can suggest a few things:

  1. You can still serialize/deserialize POJOS for documents that you KNOW that are going to remain schema-consistent
  2. You can retrieve the xml documents with unknown structure and walk over them with DOM parsers or using Java+XPath to retrieve the data that you need
  3. My preferred solution: Connect to the MarkLogic XQuery API directly (using XQJ or similar) and read the document directly. More info here.
Community
  • 1
  • 1
John Smith
  • 1,559
  • 1
  • 12
  • 18
1

Put versioning in the XML. Any decent POJO serialization should support that, or you could add it on the way into MarkLogic.

When deserializing the XML, look at the version and route to an XML library function that understands that version. That could be done in MarkLogic, or in another XQuery or XSLT processor.

mblakele
  • 7,782
  • 27
  • 45