0

I'm trying to perform get on the session for object which declares composite id without a mapped composite identifier.
Hibernate version used is 3.5.5.

Fetching code is generic and reads container objects wrapping actual data:

ClassMetadata metadata = 
          session.getSessionFactory().getClassMetadata(wrapper.getDomainClass());
Serializable id = metadata.getIdentifier(wrapper, EntityMode.POJO);
return session.get(wrapper.getDomainClass(), id, LockOptions.UPGRADE);

Code doesn't know anything about actual mapping so it has to consult metadata about the id.

If mapping is defined like:

<hibernate-mapping default-access="field">
  <class name="Wrapper"
      entity-name="Data"
      table="DATA">
    <composite-id>
      <key-property name="identifier" column="identifier" />
      <key-property name="version" column="version" />
    </composite-id>

    <component name="domainObject" class="Data">
      <property name="source" column="source" />
    </component>                    
  </class>
</hibernate-mapping>

without composite identifier class, id is equal to the object itself and is equal to wrapper reference.
When I do session.get() instead of fetching object from the database, it returns back same object as was passed in id (not an equal object, but same instance of object).
Upd: In fact session.get() loads object from database in the id object passed and returns it back. I oversaw that initially thinking it skips loading.

Solution that I found so far is introduce mapped composite identifier and change mapping to:

<hibernate-mapping default-access="field">
  <class name="Wrapper"
      entity-name="Data1"
      table="DATA_1">
    <composite-id  class="SurrogateKey" mapped="true">
      <key-property name="identifier" column="identifier" />
      <key-property name="version" column="version" />
    </composite-id>

    <component name="domainObject" class="Data">
      <property name="source" column="source" />
    </component>                    
  </class>
</hibernate-mapping>

SurrogateKey is defined as object with two fields and equals/hashcode as required.
With this change id returned by metadata.getIdentifier() is an instance of SurrogateKey and session.get() fetches object from the database if it exists.

The problem with mapping fix is that property names for criteria and HQL change from identifier to id.identifier and that is actually breaking a lot of existing code.

Things I'm exploring at the moment are:

  1. Is there a way to make session.get() work without declaring Id class (I know this is a discouraged practice, but amount of changes needed might be prohibitive)?
  2. Could the alternative be telling hibernate to treat properties as before, without adding id. in front of them?
  3. Upgrade hibernate to v4 (not easy because of dependent projects and approval process)?
  4. Any other options/workarounds available?

So far I've only managed to make a solution described above work, but I'm searching for less intrusive one and would appreciate any clues, suggestions, pointers to relevant docs.

aliher
  • 415
  • 1
  • 4
  • 13

2 Answers2

1

What is wrapper in your first code snippet? If it's an attached entity (which I suspect it is), obviously, session.get() will return the attached entity which has the same identifier, and since the identifier is the entity itself, it will return the given attached entity. There is always only one instance of any given entity in a session.

Now, to answer your questions:

  1. AFAIK, it works as expected.
  2. No.
  3. Is this a question?
  4. The best workaround is to do the right thing and stop using composite identifiers. Use single-column, auto-generated IDs, as advised by Hibernate, and everything will be much simpler.
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Wrapper is not attached to the session at the time get is done. It has at least an object key that we want to replace. Previous version could either be in database or saved in the same session. This is a batch save/update process and auto-generated id's are not an option because id's are generated by external system. If we use them, then we'll have to switch to doing queries and manually correlate objects in batches. If 1 is right behaviour only for attached entities but for detached ones it doesn't look right and it differs for mapped and non mapped keys. – aliher Jul 05 '12 at 10:14
  • With annotations, you can do what you want in your second question, by mapping several fields of the entity with @Id, and specify an ID class which has identical property names and types. Don't know if it's doable with XML mapping. – JB Nizet Jul 05 '12 at 10:25
  • I've updated initial post and posted a solution. It looks like a bug in hibernate to me now. Session doesn't take into account some aspects of instantiator's behaviour. – aliher Jul 05 '12 at 11:58
0

The problem was coming from using meaningful object as an id for session.get() method.

It turns out that session.get() has side effects and modifies its arguments (which happens deep down inside PojoInstantiator.instantiate()). On load when hibernate detects that id class is equal to mapping class it skips instance creation and uses id object passed to method instead of instantiating a new instance. This object is hydrated from database overwriting existing fields.

The solution is to make a clone of object if metadata.getIdentifier() returns object back when no key is mapped. That clone would be hydrated and returned by get().

aliher
  • 415
  • 1
  • 4
  • 13