I have a design question to do with collections and the identity of entities in the collections of newly created (ie not yet persisted) entities.
hbm2java generates hashcode & equals methods based on the identity of the entities, which seems sensible and is what I think I'd like to use.
However, as the collection (in this case a Set) requires hashcode to store the entity, you can't successfully ad a new element to one of these collections until the identity has been assigned. I'm using a hiberate id generator, and from what I can tell the id is assigned when the session.save() of the entity is called.
The collection in this case is essentially a parent child relationship (edited version below):
Code:
<hibernate-mapping>
<class name="Child" table="CHILD">
<id name="id" type="long" column="ID">
<generator class="seqhilo">
<param name="sequence">HI_VALUE_XXX_DOMAIN</param>
<param name="max_lo">100</param>
</generator>
</id>
<many-to-one name="parent"
class="Parent"
column="PARENT_ID"
not-null="true"/>
</class>
<class name="Parent" table="PARENT">
<id name="id" type="long" column="ID">
<generator class="seqhilo">
<param name="sequence">HI_VALUE_XXX_DOMAIN</param>
<param name="max_lo">100</param>
</generator>
</id>
<set name="children" lazy="true" inverse="true">
<key column="PARENT_ID"/>
<one-to-many class="Child"/>
</set>
</class>
</hibernate-mapping>
I could revert the hashCode/equals to the standard java provided (ie by object reference), but this doesn't seem the right approach in this case as the client (which is distributed from the server) will want to identify and compare objects by id (as well as possibly store in other collections), as this reflects the identify model in database.
I could change the collection type to something that doesn't require hashCode (ie a List, primative array), but this would require an index column in the schema which I don't desire (legacy data). Or I could change to a <bag> which doesn't require and index but I've been put off by some of the comments in the documentation (section 5.2) re bags and once the objects have ids I don't really want bag semantics!
I'm not sure how my client can build up a collection of new child elements add them to a parent (new or existing) and pass the updated datamodel (parent & children) to the server for update/save. Once the ids are assigned the <set> collection really does seem to be the right choice for my requirement.
It seems like I need bag semantics when creating and adding new child elements to the parent (at the client) and then <set> semantics once the changes have been sent to the server for save/update and the ids have been assigned.
I can envisage designing my POJOs to (internally) include a collection for transient (ie no id assigned yet) objects as well as persistant (id has been assigned) objects but this doesn't seem like transparent persistance.
I can also envisage not allowing clients to add transient objects to the POJO parent and instead providing operations on my remote interface to 'create/persist a bunch of new children' - in the process assigning ids, and then have the client 'add' the children to the POJO parent as 'per normal'. Again, doesn't seem like transparent persistance.
I must be missing something? Any advice - please?
Login
FAQ
Search
