|
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@xxxxxxxxx 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@xxxxxxxxxxxxx> 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
>
>
|
|
| 
