-
Notifications
You must be signed in to change notification settings - Fork 3.6k
HHH-14744 : Refactor contextual information for SchemaManagementTool to be more easily extended by Hibernate Reactive #4106
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
Thanks for your pull request! This pull request appears to follow the contribution rules. › This message was automatically generated. |
hibernate-core/src/main/java/org/hibernate/tool/schema/spi/SchemaManagementTool.java
Outdated
Show resolved
Hide resolved
I rebased main and force-pushed. |
…to be more easily extended by Hibernate Reactive HHH-14744 : Restore databases/pgsql/resources/hibernate.properties and gradle/databases.gradle
…to be more easily extended by Hibernate Reactive Move new methods out of SchemaManagementTool and into ExtractionTool
…to be more easily extended by Hibernate Reactive Add Javadoc and other minor changes to make it easier to review
I added some Javadoc and some other minor changes to be more consistent with I also force-pushed. |
Thanks @gbadner , this is larger than I expected and is changing some internal services which we use in Quarkus. I'll need to verify the feasibility of upgrading the Quarkus integration code as well. |
@Sanne, I can create default methods. I didn't do that because interfaces were marked |
@gbadner don't worry for the SPI, it seems Quarkus is compiling just fine. But we're having a memory leak which has been preventing me to run all integration tests - sorry this will take a bit longer. |
@Sanne, that's fine. I made a couple of changes here that will affect the hibernate-reactive PR, so I'll take care of that now. |
…to be more easily extended by Hibernate Reactive Correct specifications for row order of some ResultSets.
I just pushed a minor change in Javadoc.. |
It's looking great! I'm inclined to merge it already, but could you confirm why it seems you also wanted to change the PostgreSQL Dialect semantics, and also changed |
@Sanne, actually, it looks like the
It is probably possible to move these new methods into an earlier PostgreSQL dialect. The oldest version I know I have access to is PostgreSQL 8.4, so I could see about moving them into into |
I added It will be helpful to have at least one sequence ID in this test when we start adding SchemaMigrator/SchemaValidator support for more DBs. I could change the test so that there are both generated and non-generated IDs. |
…agementTool to be more easily extended by Hibernate Reactive Remove PostgreSQL10Dialect#buildIdentifierHelper since it is no longer needed.
I just pushed a commit that removes |
schemaFilter, | ||
tableName.getTableName().getText(), | ||
false, // DO NOT limit to just unique | ||
true // DO require up-to-date results |
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 just noticed that true
for the approximate
argument to `DatabaseMetaData#getIndexInfo says:
approximate - when true, result is allowed to reflect approximate or out of data values; when false, results are requested to be accurate
ORM was passing true
here, meaning that approximate data is OK, but the comment is inconsistent saying that up-to-date results are required.
Which is correct?
FWIW, when DatabaseMetaData
is not used to get this information, there does not seem to be a way to request up-to-date information.
For example, MySQL documentation says that information_schema_stats_expiry=0
should be set in order to get up-to-date statistics. This is probably not what is wanted on a production database.
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.
@dreab8, any idea what the intention is here? Is this just a documentation bug?
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.
This should not delay merging this issue. I just wanted to raise it since I saw the inconsistency.
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.
not sure but I would say we want to use up-to-date info but better to ask @sebersole for a confirmation
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.
FYI, I don't see a way for Hibernate to force this for MySQL without setting a system variable.
See https://dev.mysql.com/doc/mysql-infoschema-excerpt/8.0/en/information-schema-statistics-table.html.
…agementTool to be more easily extended by Hibernate Reactive Move methods from PostgreSQL10Dialect into PostgreSQL81Dialect; remove @GeneratedValue from SchemaUpdateTest
@Sanne, I've added a commit that moves a couple of methods from I also restored I will ask about updating Is there anything else that needs to be done before merging this? |
…to be more easily extended by Hibernate Reactive Remove SequenceInformationExtractorPostgresSQLDatabaseImpl and PostgreSQL10Dialect#getSequenceInformationExtractor
I was able to fix this in |
We should reproduce those changes in H6 I guess. Actually, eventually we're going to have to replicate all this work across. |
@Sanne, can this be merged? |
…to be more easily extended by Hibernate Reactive Add MySQLDialect#getNameQualifierSupport
I've added a commit that is required for MySQL. I checked that the setting returned by FYI, |
…to be more easily extended by Hibernate Reactive 1. Add CockroachDB192Dialect#getNameQualifierSupport and #buildIdentifierHelper. 2. Change semantics for AbstractInformationExtractorImpl#processIndexInfoResultSet to be more friendly to subclasses.
I just added a commit that:
|
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.
Thanks @gbadner !
I'll merge this soon but would prefer to branch first. |
Merging this in ORM 5.6 (current |
@@ -566,6 +567,11 @@ public JDBCException convert(SQLException sqlException, String message, String s | |||
}; | |||
} | |||
|
|||
@Override | |||
public NameQualifierSupport getNameQualifierSupport() { | |||
return NameQualifierSupport.CATALOG; |
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.
Copying comment from initial commit:
Shouldn't it be NameQualifierSupport.SCHEMA and not CATALOG (since MySQL use the concept of schema and not the catalogs).
Whenever there would be an Entity class annotated with @Table(schema = "tech", name = "point")
, the class QualifiedObjectNameFormatterStandardImpl would format the name into point
and not the tech.point
(since it does not define catalog)
https://hibernate.atlassian.net/browse/HHH-14744