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

Introduce generateStatementsFromRows for extensions #2686

Merged
merged 7 commits into from
May 17, 2022

Conversation

fbiville
Copy link
Contributor

This will allow extensions to override just the statement
generation while relying on the existing CSV parsing logic.

This is needed by the Neo4j extension.

}
}
if (rows.stream().anyMatch(LoadDataRowConfig::needsPreparedStatement)) {
// If we have only prepared statements and the database supports batching, let's roll
Copy link
Contributor Author

@fbiville fbiville Mar 25, 2022

Choose a reason for hiding this comment

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

I think the refactoring exhibits a bit more clearly a potential bug that was already there (not sure it has practical implications at all).

"any prepared statements" gets conflated with "only prepared statements". As a result, regular statements will be skipped as soon as 1 prepared statement is created.

@kataggart kataggart added this to To Do in Conditioning++ via automation Mar 28, 2022
@fbiville fbiville marked this pull request as ready for review March 31, 2022 14:09
@fbiville
Copy link
Contributor Author

Note: all existing tests for this class pass locally and I added an extra one.

This will allow extensions to override just the statement
generation while relying on the existing CSV parsing logic.

This is needed by the Neo4j extension.
Copy link
Contributor

@nvoxland nvoxland left a comment

Choose a reason for hiding this comment

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

The changes look good. I moved the LoadDataRowConfig inner class definition to the bottom since that's where they tend to be in the liquibase code, and made databaseSupportsBatchUpdates() into just supportsBatchUpdates()

Otherwise, I see how you just moved around the existing code and appreciate the extra unit test.

@github-actions
Copy link

github-actions bot commented Apr 15, 2022

Unit Test Results

  4 512 files  ±  0    4 512 suites  ±0   33m 0s ⏱️ - 3m 14s
  4 414 tests +  1    4 200 ✔️ +  1     214 💤 ±0  0 ±0 
52 248 runs  +12  47 240 ✔️ +12  5 008 💤 ±0  0 ±0 

Results for commit 8cc3c34. ± Comparison against base commit 56344fe.

♻️ This comment has been updated with latest results.

@kataggart
Copy link
Contributor

@nvoxland do we need to update any docs here?

@nvoxland
Copy link
Contributor

No we don't need additional docs. This change will be captured in the generated javadocs well enough

@kataggart kataggart added this to the NEXT milestone May 12, 2022
@nvoxland nvoxland removed their assignment May 14, 2022
Copy link
Contributor

@XDelphiGrl XDelphiGrl left a comment

Choose a reason for hiding this comment

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

  • Change impacts only those who override generateStatementsFromRows from a Liquibase extension.
  • New test added validating the override.
  • Code refactored to be more readable (thanks, @fbiville !!).
  • No further testing required.

APPROVED

Passing Harness Tests
Passing Functional Tests

@XDelphiGrl XDelphiGrl self-assigned this May 16, 2022
@nvoxland nvoxland merged commit de76719 into liquibase:master May 17, 2022
Conditioning++ automation moved this from To Do to Done May 17, 2022
@fbiville fbiville deleted the load-data-refactoring branch May 17, 2022 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

5 participants