You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by William Speirs <ws...@apache.org> on 2012/12/13 23:47:08 UTC
[DBUTILS] Updates for v2.0
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-
Re: [DBUTILS] Updates for v2.0
Posted by sebb <se...@gmail.com>.
On 13 December 2012 22:47, William Speirs <ws...@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?
If the Maven coordinates are changed, the package name must change,
and vice-versa, or there will be problems with Maven classpaths.
It's only *necessary* to change names if binary compatibility is broken.
Even if not using Maven, the package name must be changed if binary
compat. is broken.
[This is because of the way that Java classes are loaded]
I think it's a bad idea to change the names *just* because they are
not "standard", as users will have to change all their source and
rebuild.
Effectively one is releasing a brand new component and asking users to
switch to it.
> Bill-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Updates for v2.0
Posted by William Speirs <ws...@apache.org>.
>
> If the entire API is to change, then I agree one might as well treat
> it as a completerly new library and change groupId/package name.
> Users could either stick with the current design or rewrite to use the
> new design.
>
I guess the question is, are you in favor of changing a great deal of the
API to add named parameters? Currently the major benefit of DBUtils is that
you don't have to clean-up after yourself. This would add a second and very
major selling point: you don't have to count questions marks to line-up
parameters.
> The risk is that some end-users won't want to switch, and may drift
> way from the orginal library if it is not being maintained.
>
There isn't much being done to DBUtils currently, and I don't think people
are walking away from it because it's not maintained. If people are leaving
DBUtils -- I would guess -- it's because they're going after something more
powerful like Hibernate, and DBUtils was never meant to compete with the
likes of Hibernate.
> But if the intent is only to add some new elements to the API, doing
> so in an incremental, binary-compatible way would allow endusers much
> more flexibility in upgrading.
>
I agree that adding features in a binary-compatible way is always the
preference. What makes me nervous is now we'll have a whole slew of
deprecated methods in QueryRunner which looks ugly and can be confusing to
someone new. There are already 4 versions of the query method that are
deprecated, and this would potentially add 4 more! My proposal would be to
eliminate all of them in v2.x and add just a single query method with bind
methods that can be called on the returned object.
> It would be useful to show some examples of how the fluent style
> compares with the existing style before proceeding.
>
> At the moment I'm not convinced that it would be a major benefit.
Beyond the examples I gave before, what would you like to see?
I'm not saying we HAVE to use the fluent style (although I do like it), but
I would really like to see named parameters in DBUtils. For smaller
projects I still use the library, but it drives me nuts when I have to
modify an SQL query and then play the counting game with the question marks
to make sure I'm passing all the right parameters in order. The major
benefit of this update would be to add named parameters (in a fluent or
otherwise fashion).
Thanks again!
Bill-
Re: [DBUTILS] Updates for v2.0
Posted by sebb <se...@gmail.com>.
On 6 January 2013 14:50, Bill Speirs <bi...@gmail.com> wrote:
> 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.
Or you could use a Map to hold the names and values.
> 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);
Here one could use a List.
> 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.
It would simplify Nexus maintenance.
But the extra work involved in setting up non-standard Nexus projects
is a one-off for one organisation (the ASF), whereas a groupId change
would require extra work by all downstream users, and anyway most of
these have been set up already.
So yes, if we need to change package name for reasons of binary
compatibility, we should take the opportuntity to change the group id.
But changing the group id for the sake of it does not make any sense,
particularly for relatively low-level library projects such as
Commons.
> 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.
If the entire API is to change, then I agree one might as well treat
it as a completerly new library and change groupId/package name.
Users could either stick with the current design or rewrite to use the
new design.
The risk is that some end-users won't want to switch, and may drift
way from the orginal library if it is not being maintained.
But if the intent is only to add some new elements to the API, doing
so in an incremental, binary-compatible way would allow endusers much
more flexibility in upgrading.
> 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.
Yes, that's necessary. Both have to change together.
>> 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.
There are some outstanding JIRA issues (mostly enhancement requests).
Do any of these need to be addressed to bring 1.x up to date?
> 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?
It would be useful to show some examples of how the fluent style
compares with the existing style before proceeding.
At the moment I'm not convinced that it would be a major benefit.
> Bill-
>
> [1] http://wiki.apache.org/apachecon/HackathonNA13
>
>
>
> On Sat, Jan 5, 2013 at 3:52 PM, sebb <se...@gmail.com> wrote:
>
>> On 14 December 2012 01:12, William Speirs <ws...@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" <ga...@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 <ws...@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-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Updates for v2.0
Posted by Bill Speirs <bi...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 14 December 2012 01:12, William Speirs <ws...@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" <ga...@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 <ws...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBUTILS] Updates for v2.0
Posted by sebb <se...@gmail.com>.
On 14 December 2012 01:12, William Speirs <ws...@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" <ga...@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 <ws...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DBUTILS] Updates for v2.0
Posted by William Speirs <ws...@apache.org>.
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.
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?
My vote, yes... keep a 1.x branch around for those who cannot or won't
change, and 2.x for those who can.
Bill-
On Dec 13, 2012 8:04 PM, "Gary Gregory" <ga...@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 <ws...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DBUTILS] Updates for v2.0
Posted by Gary Gregory <ga...@gmail.com>.
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 <ws...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org