Menu
▾
▴
#239 update collection mapping with defined primary key
open
nobody
5
2011-10-11
2011-10-11
No
Currently, non cumulative collection mapping always uses equals (resp. contains or indexOf) to figure out if two objects are equal and therefore should be mapped/updated.
This works as expected. However this is limited to the case that equals and hashCode can be implemented. In some cases, there are classes where we are not able to override equals and hashCode (some business object coming from other services such as SOAP web services, ...).
Other issues occur when equals is for instance implemented as a full fledge equals (all values are compared) but such equals won't be useful in dozer.
Therefore I would suggest following idea:
On a class basis, a primary key could be defined. When such a primary key is defined, dozer will use this defined primary key to figure out whether a object is available in a collection which needs to be updated.
When there is no primary key equals we be used as it is implemented now.
Here is a sample xml snippet how this could look like:
<mapping>
<class-a>org.someclass.TestClass</class-a>
<class-a-pk-key>artnr</class-a-pk-key>
<class-a-pk-key>extartnr</class-a-pk-key>
<class-b>org.someclass.TestOtherClass</class-b>
...
</mapping>
As we need such a feature on a regular basis in our company, we would invest some time to implement this. My question however is, if you think, this would fit into the concept of dozer and whether such a addition would be welcome?
Adding primary key for mappings
I've attached a patch which implements such a feature.
This is not a final version (even though it is working code we already use in our use cases). It is rather a base which can be used for discussions. If you think this is the way to go, I'm willing to also adjust the documentation or further adjusting the code as well.
Just let me know what you think.
About the patch:
I've created the patch with git against trunk. However it can be applied with: patch -i add-pk-key-handling.patch -p1