Return-Path: Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list ibatis-user-java@incubator.apache.org Received: (qmail 46777 invoked by uid 99); 30 Nov 2004 22:17:01 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=FORGED_RCVD_HELO,HTML_20_30,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.plumcreek.com (HELO cfo-msg.plumcreek.net) (208.4.182.150) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 30 Nov 2004 14:17:00 -0800 Received: from plumcreek-MTA by cfo-msg.plumcreek.net with Novell_GroupWise; Tue, 30 Nov 2004 15:16:57 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Date: Tue, 30 Nov 2004 15:16:23 -0700 From: "Brandon Goodin" To: ,, Subject: Re: A few dumb questions Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part5373B327.2__=" X-Virus-Checked: Checked This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5373B327.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 > > --=__Part5373B327.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Description: HTML

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/inser= t/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.
>&n= bsp;
> Brandon
>
>

<= /HTML> --=__Part5373B327.2__=--