ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject RE: Exit out of rowHandler
Date Thu, 31 Jan 2008 03:41:47 GMT
Absolutely.  iBATIS 2.0 came with a compatibility kit back to 1.x that
allowed you to either convert your SQL Maps statically, or have them
converted dynamically at runtime so you could use 1.x maps and code with the
2.0 engine...

While I was proud of that, it did keep me from doing a few things I wanted
to.  So 3.0 will be the first in 6 years that won't be directly backward
compatible.  It will allow us to move the framework forward to a new level
and take advantage of some new technology and modern design philosophies.

Cheers,
Clinton



-----Original Message-----
From: Chris Lamey [mailto:clamey@localmatters.com] 
Sent: January-30-08 6:32 PM
To: user-java@ibatis.apache.org
Subject: RE: Exit out of rowHandler

Yes, please keep backwards compatability within minor releases.

-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Wed 1/30/2008 6:11 PM
To: user-java@ibatis.apache.org; lmeadors@apache.org
Subject: RE: Exit out of rowHandler
 
Hehe...

Well, considering how much effort I've always put into iBATIS being backward
compatible, why break tradition now?  ;-)  We can use an adapter and create
a new RowHandler interface.  

iBATIS 3.0 can merge them into one...as it won't be fully backward
compatible anyway.  

Clinton

-----Original Message-----
From: larry.meadors@gmail.com [mailto:larry.meadors@gmail.com] On Behalf Of
Larry Meadors
Sent: January-30-08 4:43 PM
To: user-java@ibatis.apache.org
Subject: Re: Exit out of rowHandler

Meh, it'll break compatibility, but it adds a great deal of useful
functionality for very little cost. In addition, the 'fix' is to add a
"return true;" to existing code. I wouldn't consider that particularly
onerous...unless you have like 1000 row handlers, in which case, you
probably *deserve* some pain. ;-)

I think it's a great idea.

Larry


On Jan 30, 2008 2:45 PM, Jeff Butler <jeffgbutler@gmail.com> wrote:
> I can't think of any other use for the return value, so I like the idea.
> The only drawback is that this will break existing row handlers.  This
could
> be an argument in favor of the two parameter approach - because it could
be
> an overloaded method.  Of course, any change to the interface is going to
> cause headaches for existing row handlers.  Maybe we should provide
adapter
> classes like AWT?
>
> <shudder>Did I just suggest using AWT as a model?</shudder>
>
> Jeff Butler
>
>
>
> On Jan 30, 2008 1:17 PM, Clinton Begin <clinton.begin@gmail.com> wrote:
>
> >
> > Hmmm... would it be horrible if the return value of handleRow() was a
> > boolean for "continue"?
> >
> > // don't mind the verbosity or any misplaced
> > // capital letters...thank you outlook
> > public boolean handleRow (Object valueObject) {
> >  boolean continue = true;
> >  if (someCondition) {
> >    continue = false;
> >  }
> >  return continue;
> > }
> >
> > I hate to suggest making use of the return value, because there is only
> > one...but it isn't used right now.  Is this the best use of the return
> > value? The alternative is to use a second parameter for controls...
> >
> > public void handleRow (ResultSetControl control, Object valueObject) {
> >  if (someCondition) {
> >    control.setContinue(false);
> >  }
> > }
> >
> > Sorry if this has already been discussed, it's more of a dev@ issue, but
> > since we're talking about it here...
> >
> > Thoughts?
> >
> > Clinton
> >
> >
> >
> >
>




Mime
View raw message