ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: Proposed Enhancement - Support Multiple Parameter Classes
Date Wed, 11 Oct 2006 03:11:57 GMT
+1.  I understand your problem and I understand the proposed solution.


At this time, you can achieve this using a HashMap:

params.put("Customer", customer);
params.put("DBTrash", dbTrash);

sqlMap.insert("statement", params)

<insert ... paramterClass="HashMap">

That said, I've been thinking iBATIS 3 should take a multiple parameter
support approach.  This may increase the verbosity of the Java API and the
XML files, but it would clean up the mess above.  And it might be possible
to support the APIs for single and multiple parameters...

Anyway.  Long story short, I agree for iBATIS 3, I'd like to see this.  But
for iBATIS 2.x, I don't think we should add this...it might cut accross too
many seams.


On 10/10/06, Jeff Butler <jeffgbutler@gmail.com> wrote:
> Hi All,
> We have an issue that I believe is quite common with enterprise
> databases.  Many (most) of the tables contain fields that are necessary for
> insert/update, but those fields do not really belong in our domain objects.
> These fields are often related to audit tracking in the tables (update
> timestamp, update user, update process, etc.).
> In my mind, these fields are DB trash that do not belong in domain
> objects.  However, if we build our POJOs without the DB trash, inserts and
> updates become problematical.  We've tried these approaches to the problem:
> 1. Put every field in a Map for insert/update, pass the Map as parameter
> object
> 2. Put the POJO in a Map, add the DB trash to the Map, pass the Map as a
> parameter object
> 3. Create some special subclass of the POJO that adds the DB trash, then
> do the get/set dance to populate the subclass and pass the subclass as a
> parameter object
> 4. Create pseudo POJOs that exactly match the table, do the get/set dance
> from our real POJOs to the table specific POJOs, and then fill in the DB
> trash columns as appropriate in the table specific POJOs
> Each of these approaches has a particular smell - sometimes forcing the
> use of Maps, sometimes forcing the get/set dance, sometimes both.  I'm
> favoring #4 right now, but still - it's not optimal.
> My thought is that this whole issue could be elegantly solved if we
> allowed multiple parameter classes like this:
> <insert id="insertCustomer" parameterClass="Customer, DBTrash">
>  ...
> </insert>
> and then we added special processing for supporting a List of parameter
> objects passed in on the SqlMapClient methods.
> What are your thoughts?  Have I missed some different and better way of
> dealing with this issue?  Would this approach be too difficult to implement
> in iBATIS?
> Jeff Butler

View raw message