You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Clinton Begin <cl...@gmail.com> on 2006/08/16 07:44:23 UTC
[VOTE] iBATIS for Java 2.2.0 promote to General Availability
PMC Members,
You've no doubt seen the 2.2.0 beta release email. Unless you find any
significant problems with the build, please now vote for iBATIS for Java
2.2.0 to be promoted to General Availabilty status.
This vote will close Friday, August 18th.
Best regards,
Clinton
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Larry Meadors <lm...@apache.org>.
Heh, calling employeeDao.delete(...) seems explicit to me. ;-)
It also lets me make them extend a common base dao that does all the work
for me:
===
public class CrudDaoImpl<Type, KeyType>
extends SqlMapClientTemplate
implements CrudDao<Type, KeyType> {
protected String namespace;
Logger log = Logger.getLogger(CrudDaoImpl.class);
public CrudDaoImpl() {
namespace = ((Class) ((ParameterizedType)getClass()
.getGenericSuperclass())
.getActualTypeArguments()[0]).getSimpleName();
if (log.isDebugEnabled())
log.debug("namespace for " + getClass() + " is " + namespace);
}
public Object insert(Type bean) {
return insert(namespace + ".insert", bean);
}
public int update(Type bean) {
return update(namespace + ".update", bean);
}
public int delete(Type bean) {
return delete(namespace + ".delete", bean);
}
...
}
===
Larry
On 8/16/06, Clinton Begin <cl...@gmail.com> wrote:
>
>
> That will teach you for not naming your methods explicitly. Delete?
> Delete what? ;-)
>
> Good point though Larry. If you design your DAOs to be very small and
> follow some convention like select, insert, update, delete....you might have
> this problem. As a more general solution, I'd suggest just choosing
> different language like: load, fetch, save, update, remove.
>
> That will avoid the whole problem.
>
> Cheers,
> Clinton
>
>
> On 8/16/06, Larry Meadors <lmeadors@apache.org > wrote:
> >
> > +1 with a warning to upgraders that almost got me.
> >
> > If you have a class defined like this:
> >
> > public class MyDaoImpl extends SqlMapDaoTemplate implements MyDao
> >
> > ...and a method like this:
> >
> > public void delete (String key)
> >
> > It won't compile until you rename your delete because it thinks you are
> > trying to override delete, and not returning and int value.
> >
> > This could be a bigger problem if your local delete method DOES return
> > int. Things that call delete(String mappedStatementName) won't behave quite
> > as expected, because they will call the overridden version instead.
> >
> > Larry
> >
> >
> >
> > On 8/15/06, Clinton Begin < clinton.begin@gmail.com> wrote:
> > >
> > >
> > > PMC Members,
> > >
> > > You've no doubt seen the 2.2.0 beta release email. Unless you find
> > > any significant problems with the build, please now vote for iBATIS for Java
> > > 2.2.0 to be promoted to General Availabilty status.
> > >
> > > This vote will close Friday, August 18th.
> > >
> > > Best regards,
> > >
> > > Clinton
> > >
> >
> >
>
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Clinton Begin <cl...@gmail.com>.
That will teach you for not naming your methods explicitly. Delete? Delete
what? ;-)
Good point though Larry. If you design your DAOs to be very small and
follow some convention like select, insert, update, delete....you might have
this problem. As a more general solution, I'd suggest just choosing
different language like: load, fetch, save, update, remove.
That will avoid the whole problem.
Cheers,
Clinton
On 8/16/06, Larry Meadors <lm...@apache.org> wrote:
>
> +1 with a warning to upgraders that almost got me.
>
> If you have a class defined like this:
>
> public class MyDaoImpl extends SqlMapDaoTemplate implements MyDao
>
> ...and a method like this:
>
> public void delete (String key)
>
> It won't compile until you rename your delete because it thinks you are
> trying to override delete, and not returning and int value.
>
> This could be a bigger problem if your local delete method DOES return
> int. Things that call delete(String mappedStatementName) won't behave quite
> as expected, because they will call the overridden version instead.
>
> Larry
>
>
>
> On 8/15/06, Clinton Begin <cl...@gmail.com> wrote:
> >
> >
> > PMC Members,
> >
> > You've no doubt seen the 2.2.0 beta release email. Unless you find any
> > significant problems with the build, please now vote for iBATIS for Java
> > 2.2.0 to be promoted to General Availabilty status.
> >
> > This vote will close Friday, August 18th.
> >
> > Best regards,
> >
> > Clinton
> >
>
>
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Larry Meadors <lm...@apache.org>.
+1 with a warning to upgraders that almost got me.
If you have a class defined like this:
public class MyDaoImpl extends SqlMapDaoTemplate implements MyDao
...and a method like this:
public void delete (String key)
It won't compile until you rename your delete because it thinks you are
trying to override delete, and not returning and int value.
This could be a bigger problem if your local delete method DOES return int.
Things that call delete(String mappedStatementName) won't behave quite as
expected, because they will call the overridden version instead.
Larry
On 8/15/06, Clinton Begin <cl...@gmail.com> wrote:
>
>
> PMC Members,
>
> You've no doubt seen the 2.2.0 beta release email. Unless you find any
> significant problems with the build, please now vote for iBATIS for Java
> 2.2.0 to be promoted to General Availabilty status.
>
> This vote will close Friday, August 18th.
>
> Best regards,
>
> Clinton
>
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Sven Boden <li...@pandora.be>.
+1 for 2.2.0 beta ;-)
Regards,
Sven
Clinton Begin wrote:
> PMC Members,
>
> You've no doubt seen the 2.2.0 beta release email. Unless you find any
> significant problems with the build, please now vote for iBATIS for Java
> 2.2.0 to be promoted to General Availabilty status.
>
> This vote will close Friday, August 18th.
>
> Best regards,
>
> Clinton
>
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Ted Husted <hu...@apache.org>.
On 8/16/06, Clinton Begin <cl...@gmail.com> wrote:
> This vote will close Friday, August 18th.
Hmmm, a quality vote never really "closes". If we find an issue with
the build next week, or next month, or next year, we can change our
votes and downgrade the quality.
The convention is to wait 72 hours before taking action on something
brought up as a vote, just to give other people a chance to reply.
That period of time doesn't make the vote "written in stone", it's
just a reasonable time to stand-by before plunging forward.
So, if 68 hours from now, there are 3 binding +1s and more +1s than
-1s, we could tag the build "GA". But, if sometime after that, other
PMC members voted for another grade, we would change the grade.
Likewise, if don't have quorum in 68 hours, people can continue to
vote, and we assign a grade as soon as we do have a quorum.
The two ideas behind the process are:
(1) We want to be sure the release is supported by a group of
individuals, and not just a sole developer. If there are not three PMC
members ready, willing, and able to support the release, then the bits
are not ready for the Apache iBATIS brand.
(2) That we tell the truth. Quality is a judgment call. Future events
could affect our judgment of the quality of the bits, and we reserve
the right to change our judgment based on actual and continuing
experience.
HTH, Ted.
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Jeff Butler <je...@gmail.com>.
I added the PDF dates because there was a fair amount of confusion about
which version of the PDF was actually current. I think it's a good idea
because the documentation changes so frequently, but is so rarely
published. But I'm not dogmatic about it. My main thing is that I'd like
it to be clear somehow when the documentation is updated - so when we say
RTFM, it's actually clear what FM we mean :-)
Jeff Butler
On 8/16/06, Clinton Begin <cl...@gmail.com> wrote:
>
> Nah,
>
> #1 I've uploaded the DTDs now
>
> #2 Let's fix it. That's what Betas are for. :-) Only the build number
> will change, and only the manifest files use that particular version number,
> so no biggie.
>
> I've updated the build script so that it uses the same build number for
> the filename as the manifest files, so that it's easier to spot this error
> in the future. Makes me wonder why I didn't do that long ago! :-/
>
> #3 ...as for the PDF dates...do we really need those? Seems like extra
> maintenance.
>
> Cheers,
>
> Clinton
>
>
> On 8/16/06, Jeff Butler < jeffgbutler@gmail.com> wrote:
> >
> > +1 for beta (woo hoo!)
> >
> > Issues I've noticed so far:
> >
> > 1. The new DTDs did not get copied to the web site
> > 2. The version number in version.properties did not get updated, so the
> > JARs are still tagged as version 2.1.7
> > 3. The update dates for the PDFs did not get updated on the web page
> >
> > I can deal with #1 and #3 later this evening if no one beats me to it,
> > but I think we're stuck with #2 :(
> >
> > Jeff Butler
> >
> >
> > On 8/16/06, Clinton Begin <clinton.begin@gmail.com > wrote:
> > >
> > >
> > > PMC Members,
> > >
> > > You've no doubt seen the 2.2.0 beta release email. Unless you find
> > > any significant problems with the build, please now vote for iBATIS for Java
> > > 2.2.0 to be promoted to General Availabilty status.
> > >
> > > This vote will close Friday, August 18th.
> > >
> > > Best regards,
> > >
> > >
> > > Clinton
> > >
> >
> >
>
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Clinton Begin <cl...@gmail.com>.
Nah,
#1 I've uploaded the DTDs now
#2 Let's fix it. That's what Betas are for. :-) Only the build number
will change, and only the manifest files use that particular version number,
so no biggie.
I've updated the build script so that it uses the same build number for the
filename as the manifest files, so that it's easier to spot this error in
the future. Makes me wonder why I didn't do that long ago! :-/
#3 ...as for the PDF dates...do we really need those? Seems like extra
maintenance.
Cheers,
Clinton
On 8/16/06, Jeff Butler <je...@gmail.com> wrote:
>
> +1 for beta (woo hoo!)
>
> Issues I've noticed so far:
>
> 1. The new DTDs did not get copied to the web site
> 2. The version number in version.properties did not get updated, so the
> JARs are still tagged as version 2.1.7
> 3. The update dates for the PDFs did not get updated on the web page
>
> I can deal with #1 and #3 later this evening if no one beats me to it, but
> I think we're stuck with #2 :(
>
> Jeff Butler
>
>
> On 8/16/06, Clinton Begin <clinton.begin@gmail.com > wrote:
> >
> >
> > PMC Members,
> >
> > You've no doubt seen the 2.2.0 beta release email. Unless you find any
> > significant problems with the build, please now vote for iBATIS for Java
> > 2.2.0 to be promoted to General Availabilty status.
> >
> > This vote will close Friday, August 18th.
> >
> > Best regards,
> >
> >
> > Clinton
> >
>
>
Re: [VOTE] iBATIS for Java 2.2.0 promote to General Availability
Posted by Jeff Butler <je...@gmail.com>.
+1 for beta (woo hoo!)
Issues I've noticed so far:
1. The new DTDs did not get copied to the web site
2. The version number in version.properties did not get updated, so the JARs
are still tagged as version 2.1.7
3. The update dates for the PDFs did not get updated on the web page
I can deal with #1 and #3 later this evening if no one beats me to it, but I
think we're stuck with #2 :(
Jeff Butler
On 8/16/06, Clinton Begin <cl...@gmail.com> wrote:
>
>
> PMC Members,
>
> You've no doubt seen the 2.2.0 beta release email. Unless you find any
> significant problems with the build, please now vote for iBATIS for Java
> 2.2.0 to be promoted to General Availabilty status.
>
> This vote will close Friday, August 18th.
>
> Best regards,
>
>
> Clinton
>