On 6 January 2013 14:50, Bill Speirs <bill.spe...@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 <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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
