ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <brandon.goo...@gmail.com>
Subject Re: Proposed Enhancement - Support Multiple Parameter Classes
Date Tue, 10 Oct 2006 19:10:15 GMT
I guess I don't completely understand your issue. Do you have 10 different
SqlMpas instantiated that call 10 different database and may share 1 domain
object that needs to write to all of them? This souns extreme to me.

On 10/10/06, Jeff Butler <jeffgbutler@gmail.com> wrote:
> 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