Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FINERACT-995: Rewriting logic to remove call to rs.previous() #1024

Merged
merged 1 commit into from
Jun 20, 2020

Conversation

ptuomola
Copy link
Contributor

@ptuomola ptuomola commented Jun 10, 2020

FINERACT-995

Description

Rewrote the logic to remove call to rs.previous() that was throwing an SQLException.

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

Our guidelines for code reviews is at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide

@ptuomola
Copy link
Contributor Author

@vorburger @xurror - here's a quick rewrite to remove the call to rs.previous(). Unfortunately I have no sensible way of testing this - so no idea if it works! Does this look sensible and if yes, any ideas how we could test this?

@vorburger
Copy link
Member

@awasum @fynmanoj @avikganguly01 @vishwasbabu are you able to help review this PR for FINERACT-995?

periodDatas.add(loanSchedulePeriodData);
while (rs.next()) {
Long tempLoanId = rs.getLong("loanId");
if (loanId.equals(tempLoanId)) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to understand this to the best I can but I just have the feeling that this piece of logic is missing. Can you maybe make it a little clearer for me?
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see, the logic is trying to build a map of (loanId, periodData). There may be multiple rows in the ResultSet and these must therefore be merged to be part of the same entry in the map.

The previous code does it by:

  1. Read one LoanId from resultset and create a map entry
  2. In a loop, keep fetching next row from result set.
    • If the next row has the same loanId, then add it to the same map entry and fetch next
    • If the next row has a different loanId, go back one row in result set and start from step 1

The problem is the "go back one row" which is not supported by some JDBC drivers.

But an equivalent way of building the same map (at least in my view would be):

  1. Iterate through the result set. For each row's loanId:
  • If we already have a map entry for that loanId, add the dates to the existing entry
  • If we don't yet have a map entry for that loanId, create a new one and add the dates to that

No rs.previous() required, and either way you should end up with the same Map - as far as I can see..

But I don't have a way to test this code, so a bit concerned I may have missed something...

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally makes sense now. Thanks for helping me understand this better.
I actually read a comment that suggested doing this or using caching or hashmap or any other collection to hold all the resultset and instead iterate through it as you did but it just wasn't clear to me.

Unfortunately we don't have a way testing this but I agree with your approach. Since it passes all IT tests, we can just blindly merge this 2 or 3 days if there are no objections and hope for the best 😁.

Copy link
Member

@vorburger vorburger Jun 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ptuomola sorry for delay in reviewing this (I wanted to do it with a clear mind instead of clicking through it half asleep a night after day job work...) and after staring at this a little bit, I get it now - this makes good sense to me as well, and I have no objection to merging this even without having any way to functionally test this myself either (no idea if existing ITs, recently re-enable, would catch this, but doesn't matter, it "makes sense").

One very small feedback I would have is that, now that I understand this logic, it seems to me that moving that scheduleDate.put(loanId, periodDatas); now in line 449 (originally 434) up into the if(periodDatas == null) right after the periodDatas = new ArrayList<>(); would make it a tiny bit more clear and explicit what we're doing here? It's too minor to hold back merging this important fix, so I'll just go ahead and merge it ASAP, and let you raise a very small minor follow-up PR, if you like (or not, fine). I originally wrote this before seeing the Spotless style failure, if you're going over this again, might as well do that too here - if you agree that makes sense?

@awasum
Copy link
Contributor

awasum commented Jun 12, 2020

I maybe able to look at this tomorrow..

@vorburger
Copy link
Member

/rebase

Copy link
Member

@vorburger vorburger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but the rebase failed due to Spotless (probably the { needs to be on the same line as if..) - will you fix @ptuomola ?

Thank You for this contribution - that's one more release Blocker issue (FINERACT-995) done!

periodDatas.add(loanSchedulePeriodData);
while (rs.next()) {
Long tempLoanId = rs.getLong("loanId");
if (loanId.equals(tempLoanId)) {
Copy link
Member

@vorburger vorburger Jun 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ptuomola sorry for delay in reviewing this (I wanted to do it with a clear mind instead of clicking through it half asleep a night after day job work...) and after staring at this a little bit, I get it now - this makes good sense to me as well, and I have no objection to merging this even without having any way to functionally test this myself either (no idea if existing ITs, recently re-enable, would catch this, but doesn't matter, it "makes sense").

One very small feedback I would have is that, now that I understand this logic, it seems to me that moving that scheduleDate.put(loanId, periodDatas); now in line 449 (originally 434) up into the if(periodDatas == null) right after the periodDatas = new ArrayList<>(); would make it a tiny bit more clear and explicit what we're doing here? It's too minor to hold back merging this important fix, so I'll just go ahead and merge it ASAP, and let you raise a very small minor follow-up PR, if you like (or not, fine). I originally wrote this before seeing the Spotless style failure, if you're going over this again, might as well do that too here - if you agree that makes sense?

@@ -73,6 +73,7 @@ script:
# using "&&" instead of several "-" means that integrationTest does not run if test fails,
# and Docker test does not run if integration test fails, which makes PR failure easier to understand.
# @see https://docs.travis-ci.com/user/job-lifecycle/#customizing-the-build-phase
# NOTE: Sleep after docker-compose increased to 60 seconds as often Travis would fail to get Docker up in 30 seconds
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ptuomola just noticed while merging this that you haven't actually changed the sleep 30s so this comment is perhaps a left over? I'll merge this PR anyway, you can always clean it up later, if you like.

@vorburger vorburger merged commit 6438063 into apache:develop Jun 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants