visruth opened a new pull request #7: get generated keys from
queryRunner.insertBatch
URL: https://github.com/apache/commons-dbutils/pull/7
This class will be useful to get generated keys from the
queryRunner.insertBatch operation.
Eg:-
```
ResultSetHandler> rsh = new
Good idea. Another user commented something similar in the pull request, and I
believe Rob's suggestion was in the same direction.
Here's a PR that fixes clirr and deprecates a few things for 2.0:
https://github.com/apache/commons-text/pull/102
Thanks!
Bruno
On Wednesday, 20 February
Same for me. Just provided a solution to unblock 1.7, but happy to go with a
2.0 if we others agree too.
I haven't followed much around the Java modules. But this is a good opportunity
to fix anything required for the new Java versions.
CheersBruno
On Thursday, 21 February 2019, 10:59:11
kinow commented on issue #102: TEXT-104: deprecate JaroWinkler methods for 2.0,
and fix clirr report
URL: https://github.com/apache/commons-text/pull/102#issuecomment-465772523
Clirr report:
Sounds reasonable. But I suppose the question we should ask ourselves is: do we
want a 1.7 or a 2.0? I’d be happy with either.
-Rob
> On Feb 20, 2019, at 4:56 PM, Bruno P. Kinoshita wrote:
>
>
> We have a few things ported from Lang that are deprecated and could be
> removed.
>
>
> But
We have a few things ported from Lang that are deprecated and could be removed.
But I have reverted my change in this pull request:
https://github.com/apache/commons-text/pull/102
It introduces back the constant and the method removed, and also uses the old
code for the edit distance. But
kinow opened a new pull request #102: TEXT-104: deprecate JaroWinkler methods
for 2.0, and fix clirr report
URL: https://github.com/apache/commons-text/pull/102
This PR makes the Clirr report pass for 1.7. It keeps the new
`JaroWinklerSimilarity` class, but reverts the change in
Are we really ready for a 2.0? How much deprecated stuff do we carry?
I plan on taking a closer look at the jarod distance issue tonight or
tomorrow.
Gary
On Wed, Feb 20, 2019, 13:33 Pascal Schumacher I'm fine with either solution, but my preference would be to remove all
> deprecated stuff
+1
Oliver
Am 19.02.19 um 22:35 schrieb Marcelo Vanzin:
> I'm opening a vote based on recent discussions about the extra noise
> generated by github updates going to dev@. So please vote:
>
> - +1 to redirect github updates of all commons repos to the issues@ list
> - -1 to keep things as is
>
On Wed, Feb 20, 2019 at 11:13 AM Pascal Schumacher
wrote:
> Am 20.02.2019 um 19:39 schrieb Marcelo Vanzin:
> > Rob:
> >> I almost think that we should have Pull Requests generate jiras.
> > I've seen this set up in a couple of projects and jira becomes
> > unreadable... the updates generated by
Am 20.02.2019 um 19:39 schrieb Marcelo Vanzin:
Rob:
I almost think that we should have Pull Requests generate jiras.
I've seen this set up in a couple of projects and jira becomes
unreadable... the updates generated by github are horrible to read. I
really don't like them.
Imho the way to
On Wed, Feb 20, 2019 at 5:41 AM Gary Gregory wrote:
> Is this a LAZY VOTE?
Sorry, but not familiar with the semantics of when to call a lazy vs.
non-lazy vote. Given the current number of votes, does it matter?
Rob:
> I almost think that we should have Pull Requests generate jiras.
I've seen
I'm fine with either solution, but my preference would be to remove all
deprecated stuff and release version 2.0.
Am 20.02.2019 um 08:42 schrieb Bruno P. Kinoshita:
Hi all,
Just finished merging a pull request to TEXT-104, where the JaroWinkler
distance was updated. The class was actually
+1
On Wed, 20 Feb 2019, 3:05 am Marcelo Vanzin,
wrote:
> I'm opening a vote based on recent discussions about the extra noise
> generated by github updates going to dev@. So please vote:
>
> - +1 to redirect github updates of all commons repos to the issues@ list
> - -1 to keep things as is
>
>
+1
On February 20, 2019 at 08:41:15, Gary Gregory (garydgreg...@gmail.com)
wrote:
Is this a LAZY VOTE?
Gary
On Wed, Feb 20, 2019 at 7:36 AM Rob Tompkins wrote:
> +1
>
> (Note. We still need to have the github messages either land on an email
> list or generate jira’s for traceability. I
Is this a LAZY VOTE?
Gary
On Wed, Feb 20, 2019 at 7:36 AM Rob Tompkins wrote:
> +1
>
> (Note. We still need to have the github messages either land on an email
> list or generate jira’s for traceability. I almost think that we should
> have Pull Requests generate jiras.)
>
> > On Feb 19, 2019,
+1
(Note. We still need to have the github messages either land on an email list
or generate jira’s for traceability. I almost think that we should have Pull
Requests generate jiras.)
> On Feb 19, 2019, at 4:35 PM, Marcelo Vanzin
> wrote:
>
> I'm opening a vote based on recent discussions
> On Feb 20, 2019, at 5:42 AM, Benedikt Ritter wrote:
>
> Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita <
> ki...@apache.org>:
>
>> Hi all,
>> Just finished merging a pull request to TEXT-104, where the JaroWinkler
>> distance was updated. The class was actually computing a
Am Mi., 20. Feb. 2019 um 08:58 Uhr schrieb Bruno P. Kinoshita <
ki...@apache.org>:
> Hi all,
> Just finished merging a pull request to TEXT-104, where the JaroWinkler
> distance was updated. The class was actually computing a text similarity
> score, not an edit distance. The user that
I'm happy about the positive feedback. I'm currently a little bit busy at
work. I hope to be able to spike something at the end of next week.
Benedikt
Am Mo., 18. Feb. 2019 um 20:25 Uhr schrieb Matt Sicker :
> The DSL allows you to break out into parallel stages or sequential
> ones (or both).
+1
Am Di., 19. Feb. 2019 um 22:35 Uhr schrieb Marcelo Vanzin
:
> I'm opening a vote based on recent discussions about the extra noise
> generated by github updates going to dev@. So please vote:
>
> - +1 to redirect github updates of all commons repos to the issues@ list
> - -1 to keep things as
21 matches
Mail list logo
