Hi,
I know I threw this question out before but I've just had a few more thoughts about this.
The idea was to have a single resultmap for an entire table/domain class mapping which can be reused in multiple <select> statements without the select statement providing every column specified in the result map.
I love result maps except for this fact. I love it more then the automapping (i.e select column as property) because it keeps my sql super clean. I hope they are never removed.
My thoughts are as follows:
1. I can't think of a reason why we have to tie the resultmap stiffly to the <select> statement in terms of the column mapping. I always just check my select statement to see what columns it returns and from that I know I always map particular columns to particular properties.
2. In my DAOs I call particular select statements (I don't even think about resultmaps) so again I check my select statements for what I can expect. If I were to change the select statement, having the resultmap tied closely would not help me much, because I would just change both. My unit test would help me ensure that I have not missed something in my select statements. I would not rely on the resultmaps to ensure consistency. In fact, having to write out multiple resultmaps for the same domain object is more error prone and confusing (if I use extends alot).
If someone can help me understand the reason why we have to have this close relationship between resultmaps and <select> statements then I can rest easy that what I'm currently doing is in fact the best way.
I've survived without this (and will continue to do so without it), but I'm greedy and I'd like to have my cake with icing on top :-)
Thanks and Best Regards,
Huy
