In thinking about it more (I haven't started implementing anything yet), I
don't see why we would want to drop support for positional parameters... we
could easily handle both. (Both in the same piece of SQL might get tricky,
but that's easy enough to detect and throw an exception.)
As for how named parameters should be supported I was thinking of making
QueryRunner into a more fluent style API that would look something like:
qr.query("select * from blah where foo = :foo and bar = :bar").bind("foo",
myFoo).bind("bar", myBar).execute(resultHandler);
This presents the issue that the query method now must return an
intermediate object that holds the state of the sql query (so QueryRunner
itself can remain thread safe). Each call to bind will simply add to that
state and return that object. This makes things a bit more complex, but the
user *should* be none the wiser. If we wanted to use positional parameters
it would simply look like:
qr.query("select * from blah where foo = ? and bar = ?").bind(1,
myFoo).bind(2, myBar).execute(resultHandler);
It is really the change to the interface and the addition of named
parameters that I'd like to promote more than deprecating positional
parameters.
> Users will have to switch to named parameters AND change package names at
the same time. Seems unnecessary to do this in one big bang.
It was my understanding that the ASF would like to encourage projects to
move towards the org.apache.commons coordinate system for maven. Since my
idea is a somewhat radical change to how DBUtils will be used (fluent style
with bind methods instead of all parameters in one call), I was thinking
this would make for a logical departure from our current maven coordinates.
The only way I know to switch Maven coordinates is to also change the
package names so if someone includes both there won't be collisions and
confusion. Version 2.x would live at org.apache.commons with a package of
o.a.c.dbutils2 and version 1.x still lives at commons-dbutils with
o.a.c.dbutils.
> Are there enough developers to support both 1.x and 2.x?
I've probably been the most active developer on DBUtils lately, and I've
done very, very little work. DBUtils "just works" as it stands now in the
1.x branch, so I don't think we'd need much more help there. As for 2.x, my
plan is to implement these changes at ApacheCon NA and try
to recruit others to help [1]... so far, no luck.
Sebb, as always thanks for the feedback! Thoughts?
Bill-
[1] http://wiki.apache.org/apachecon/HackathonNA13
On Sat, Jan 5, 2013 at 3:52 PM, sebb <seb...@gmail.com> wrote:
> On 14 December 2012 01:12, William Speirs <wspe...@apache.org> wrote:
> > Adding named params won't break things (actually I was thinking of adding
> > this to a 1.x release as well), but removing deprecated code will. Also,
> I
> > was thinking of switching to only supporting named params in the 2.x
> branch.
>
> Why drop support for positional parameters?
>
> > I guess the real question is, do folks think that forcing the use of
> named
> > params and switching to a groupid to org.apache is enough benefit for the
> > cost?
>
> Users will have to switch to named parameters AND change package names
> at the same time.
> Seems unnecessary to do this in one big bang.
>
> Why not introduce named parameters, and deprecate positional parameters?
>
> > My vote, yes... keep a 1.x branch around for those who cannot or won't
> > change, and 2.x for those who can.
>
> Are there enough developers to support both 1.x and 2.x?
>
> > Bill-
> > On Dec 13, 2012 8:04 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:
> >
> >> We only need to change the coordinates if the package name changes to
> >> account for BC breakage.
> >>
> >> Gary
> >>
> >> On Dec 13, 2012, at 17:47, William Speirs <wspe...@apache.org> wrote:
> >>
> >> > I just submitted
> >> > DBUTILS-105<https://issues.apache.org/jira/browse/DBUTILS-105> to
> >> > add support for named params to DB Utils. I'm thinking that if we
> wrapped
> >> > that up with DBUTILS-95 <
> >> https://issues.apache.org/jira/browse/DBUTILS-95>
> >> > and DBUTILS-92 <https://issues.apache.org/jira/browse/DBUTILS-92> it
> >> would
> >> > be worth cutting a new major version.
> >> >
> >> > Also, we should switch the maven convention which probably means
> changing
> >> > to commons-dbutils2 much like was done with lang.
> >> >
> >> > Thoughts?
> >> >
> >> > Bill-
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
