-
Notifications
You must be signed in to change notification settings - Fork 356
Changes to support generating Liquibase change-sets #1520
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
Conversation
kurtn718
commented
May 22, 2023
- You have read the Spring Data contribution guidelines.
- You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
- You submit test cases (unit or integration tests) that back your changes.
- You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).
Initial Data Model for Schema SQL Generation that can generate SQL for a simple entity. Closes #1478
…ween current and previous state
@@ -32,12 +32,12 @@ | |||
* @author Kurt Niemi | |||
* @since 2.0 | |||
*/ | |||
class DerivedSqlIdentifier implements SqlIdentifier { | |||
public class DerivedSqlIdentifier implements SqlIdentifier { | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open to alternatives if we don't want to make this public.
The TableModel and ColumnModel classes take in a SQLIdentifier in their constructor - and the LiquibaseChangeSetGenerator class creates a SchemaSQLGenerationModel (which I think I am going to rename/refactor to SchemaModel)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a first review pass.
spring-data-jdbc/pom.xml
Outdated
@@ -70,6 +70,17 @@ | |||
</roles> | |||
<timezone>+1</timezone> | |||
</developer> | |||
<developer> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should clean up the developer
sections as these information are inherited from parent pom's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, all of the developers should go into the parent spring-data-relational.pom? (and we remove from the spring-data-jdbc and spring-data-r2dbc) and also make sure that nobody gets deleted :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly. I assume that we missed the cleanup when we split modules and added the R2DBC module during the course of our repository rearrangement one or two years ago.
continue; | ||
} | ||
|
||
SqlIdentifier tableName = new DerivedSqlIdentifier(table.getName(), true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The usage of DerivedSqlIdentifier
isn't appropriate. DerivedSqlIdentifier
is intended to be used when creating a SQL model from Java classes. In this case, we have already a proper SQL model. I'm also not quite sure whether quoted
should be part of the identifier handling as we're working with plain table and column names.
for (liquibase.structure.core.Table table : tables) { | ||
|
||
// Exclude internal Liquibase tables from comparison | ||
if (table.getName().startsWith("DATABASECHANGELOG")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's have a table filter Predicate
to keep things extensible.
this.targetDatabase = targetDatabase; | ||
} | ||
|
||
public void generateLiquibaseChangeset(String changeLogFilePath) throws InvalidExampleException, DatabaseException, IOException, ChangeLogParseException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use Spring's Resource
abstraction instead of String
s. With string values, we can never know, whether these could be URL's, resource paths or file paths.
setIdentifierColumns.add(p); | ||
} | ||
|
||
iter = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By iterating over persistent properties, we should get all properties. We would need to ensure that properties aren't associations or entities. We should not require @Column
.
import java.util.ArrayList; | ||
import java.util.List; | ||
|
||
public class TableDiff { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should be able to use Java records for all pure data objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converted all of the pure data objects to use records. It's definitely cleaner - removing the getters/setters.
|
||
// Identify deleted tables | ||
Set<TableModel> deletedTables = new HashSet<TableModel>(sourceTableData); | ||
deletedTables.removeAll(targetTableData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be careful. Databases may contain tables that are not mapped. If we remove those tables, then we might delete their data. Another safeguard (predicate) would be good, to either have a boolean flag or a predicate to identify the tables, that can be deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still have the safe-guard in that we don't automatically apply the change set, but having user(s) modify the changeet to remove the deletions every time would be annoying :-) and also error prone.
I like the predicate idea - with the default implementation we don't delete anything, and then it's on the developer if they supply a custom predicate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mp911de - Hi, I think I've pushed up changes for everything that you had mentioned.
…rform any difference/comparison)
…bles / columns (i.e. only perform additions - unless the user implements a predicate telling us otherwise)
…en querying DB state is the Reference Name.
Reformat code, switch to tabs. Accept property in DatabaseTypeMapping to provide more context to the type mapping component. Rename LiquibaseChangeSetGenerator to …Writer as we're writing a changeset and computing the contents is a consequence of writing a changeset. Refine naming to express what we're actually doing. Introduce setters for enhanced configuration of predicates. Reduce visibility of types to avoid unwanted public API where public access is not needed. Remove usused code, move methods around for improved grouping of code.
Rename package to schema as the schema is being created and updated and not generated. Rename …Model classes to just their name as types are package-private and not visible externally. Refactor SchemaDiff to Java record. Use different overloads to write schema changes to avoid LiquibaseException leaking into cases where no diff is being used. Introduce SchemaFilter to filter unwanted mapped entities. Add tests for changeset-creation.
Move code to JDBC module. Introduce comparator strategy to customize how table and column names are compared.
Reformat code, switch to tabs. Accept property in DatabaseTypeMapping to provide more context to the type mapping component. Rename LiquibaseChangeSetGenerator to …Writer as we're writing a changeset and computing the contents is a consequence of writing a changeset. Refine naming to express what we're actually doing. Introduce setters for enhanced configuration of predicates. Reduce visibility of types to avoid unwanted public API where public access is not needed. Remove usused code, move methods around for improved grouping of code. Rename package to schema as the schema is being created and updated and not generated. Rename …Model classes to just their name as types are package-private and not visible externally. Refactor SchemaDiff to Java record. Use different overloads to write schema changes to avoid LiquibaseException leaking into cases where no diff is being used. Introduce SchemaFilter to filter unwanted mapped entities. Move code to JDBC module. Introduce comparator strategy to customize how table and column names are compared. See #1478 Original pull request: #1520
That's merged and polished now. |
Reformat code, switch to tabs. Accept property in DatabaseTypeMapping to provide more context to the type mapping component. Rename LiquibaseChangeSetGenerator to …Writer as we're writing a changeset and computing the contents is a consequence of writing a changeset. Refine naming to express what we're actually doing. Introduce setters for enhanced configuration of predicates. Reduce visibility of types to avoid unwanted public API where public access is not needed. Remove usused code, move methods around for improved grouping of code. Rename package to schema as the schema is being created and updated and not generated. Rename …Model classes to just their name as types are package-private and not visible externally. Refactor SchemaDiff to Java record. Use different overloads to write schema changes to avoid LiquibaseException leaking into cases where no diff is being used. Introduce SchemaFilter to filter unwanted mapped entities. Move code to JDBC module. Introduce comparator strategy to customize how table and column names are compared. See #756 Original pull request: #1520