Re: Proposed Enhancement - Support Multiple Parameter Classes

[Brandon Goodin]

If your enterprise requires that you display audit data then what is it that is not part of the domain? It is domain relevant data. Just because it is shared among all database tables doesn't make it non-domain. For auditing i generally have a couple of different levels. One is "single generation" and the other "historical". When handling "single generation update/insert auditing, I add a date and user field to my POJOs (one of each for insert and update). For "historical" auditing, I place a trigger that writes to another table whenever a record is updated/deleted. This maintains a truly historical auditing trail. I would encourage you to just add the "single generation" audit fields to your POJOs and be done with it.

Brandon

On 10/10/06, Jeff Butler <[EMAIL PROTECTED]> 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