IMO, it doesn't fit with the iBATIS philosophy. There are as many solutions to this as there are projects, and making a simple solution to this problem is not terribly likely.
I tend to put as much of that in the DAO (via threadlocal storage) or in the database itself (via triggers, etc) as I can. That keeps it out of the application pretty well. It might be cool to be able to get to static data from a mapped statement - so like if i create a static method on a ThreadLocal to get the user name, etc... Just my $0.02 on it. :-) Larry 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
