Hi,

I am sharding the data into hot and cold storage. When some new data is created it is created in Hot storage which requires transactions to do updates on it. Once the lifecycle is completed no updates on this data is required we move it to cold storage from where it is available only for reads (search should club the result from both hot and cold db). Since cold data is huge in volume we are using mongo for this and since we require transaction on hot we are using mysql for this. We need to work on the same entities, So should we use hibernate ogm + hibernate mysql orm for this. I have read that same entities should not be used between ogm and mysql. What is the problem with this. I have created a prototype for this which is working fine with limited use cases. What can be the potential issues that can happen because of this.

Thanks
Mayank

I think your general approach works but there are a few potential gotchas:

- the same collection instance cannot be associated with two different Hibernate sessions
- to move an entity from the ORM (mysql) session to the OGM (mongodb) session, you need to be careful with the identifier. You need on the cold session a manual id generator so that you share the id between both storages and not regenerate one. Note that there is a method on Session that tries to address some of these problems, it's called replicate.

If you have collections, I would be tempted to either use replicate or something like MapStruct to do a copy from class A to class APrime. APrime could host slightly different mapping options if needed.

I would be interesting to have such hot / cold offloading pattern once we start supporting native polyglot persistence.

Thanks emmanuel,

This is really helpful.
We don't have any use cases where we need to associate a collection instance with two different Hibernate sessions,
To move the entities around we are detaching it from one session then persisting it to other.

Till now we were not using generated values for ID's But replicate is working fine so when we will have use case like that we will use it.

Thanks a lot
Mayank.