Hello,

I'm in a situation where I'm trying to make separate databases live peacefully together. Hibernate makes that pretty easy with the CompositeUserType. Using CompositeUserType, I can use any session I need to load an Entity!

I was looking at ClassPersister, though, and wondering if this might be a better solution for "objects living in different databases" than CompositeUserType is.

I was thinking of subclassing EntityPersister and overriding the session that gets used in "load", "insert", "update", and "delete". Could it be that easy -- take control over the session used in EntityPersister?

And, would this work OK with "joins" across objects in different databases, then? CompositeUserType knows how to dereference the properties properly so that query joins on objects in separate databases works fine. Will EntityPersister be prepared for this?

If not, I'll just stick with CompositeUserType. :)

Thanks for you time!

Ryan

As an amendment to the above, I noticed that EntityPersister takes a SessionFactoryImplementor in the constructor. Does this mean that it only supports one particular class per session factory?

In the example from my previous post, one class in our system may be spread amongst many different session factories (databases locations). The idea is to make this distribution transparent to the code. This works OK with CompositeUserType, but I'm wondering if it can be achieved more elegantly with a customer perister.

Thanks again,

Ryan