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 <[EMAIL PROTECTED]> 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
