ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: A few dumb questions
Date Tue, 30 Nov 2004 22:27:20 GMT
I suppose this is not publicly available, is it ;)

Oliver


On Tue, 30 Nov 2004 15:16:23 -0700, Brandon Goodin
<brandon.goodin@plumcreek.com> wrote:
>  
> Good point. I can see the need when you are handling tabular data entry or
> some sort of batch processing. However, as you stated, IBatis could be part
> of a larger strategy that included using IBatis for the database updates and
> something else for the dirty checking. As I mentioned earlier, Clinton wrote
> a service framework for a client of his that does dirty checking of objects
> and takes action when they have been altered. It is not tied to the database
> only and lends itself to some cool applications. It was quite intriguing to
> see how it worked. 
>   
> Brandon
> 
> >>> oliver.zeigermann@gmail.com 11/30/2004 3:01:40 PM >>>
> 
> 
>  
> For my application dirty checking would improve performance quite a
> bit. Consider you have (literally) hundreds of children, but only one
> has changed and thus is needed to be stored back. This would increase
> performance by a factor of 100. Isn't this something?
> 
> However, I suppose that adding this to SQL Maps would hardly fit SQL
> Maps overall design and its primary goal of simplicity. Still, you can
> just as well do this dirty checking manually...
> 
> I will read more of the developers guide and come back with less dumb
> questions.
> 
> Oliver
> 
> On Tue, 30 Nov 2004 11:51:06 -0700, Brandon Goodin
> <brandon.goodin@plumcreek.com> wrote:
> >  
> > Okay... I think we've been addressing two different points :D 
> >   
> > 1) Caching and database/sql tuning are the only ways to solve database
> > perfromance issues 
> > 2) Dirty checking provides for the ability to perform actions against an
> > object upon changes to that object or it's properties
> > (update/insert/delete). But, does not solve performance issues 
> >   
> > We have tossed around the idea of adding some dirty checking in SQLMaps.
> > But, we have not really felt confident that it should be part of the
> SQLMap
> > layer. However, it does not exclude SQLMaps from being part of a dirty
> > checking strategy. I know that Clinton has recently done some impressive
> > work down these lines. 
> >   
> > Brandon 
> >   
> >
>

Mime
View raw message