ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Proposed Enhancement - Support Multiple Parameter Classes
Date Tue, 10 Oct 2006 18:44:14 GMT
It's not for display - it's only required for update/insert.

Maybe I need to clarify what I mean by an "enterprise database".  In our
situation, this means "separate DBA and database design group - not under
our control".  So things like stored procedures, extra triggers, and table
design changes aren't really options for us.  Most truly enterprise
databases have many different applications hitting them and they maintain
their own sets of standards.  They usually aren't open to changing things
just to make it easier for one client application.

As to whether these fields belong in the POJOs or not, this is certainly
open to debate.  An issue with it is this - one domain object could map to
many more than one DB table (we have cases where a domain object maps to
upwards of 10 tables).  Maintaining all the DB trash for these 10 different
tables in my domain object makes the object very tightly coupled with the DB
- might as well just use classes that exactly match the tables if we're
going there (this is sort of what I'm doing anyway).

I'm intrigued with Larry's idea of accessing static ThreadLocal data in a
mapped statement.  I wonder what the syntax for that would look like?

Jeff Butler

On 10/10/06, Brandon Goodin <brandon.goodin@gmail.com> wrote:
> 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

View raw message