Skip to content

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

Merged
merged 10 commits into from
Aug 25, 2021

Conversation

gbadner
Copy link
Contributor

@gbadner gbadner commented Jul 23, 2021

@hibernate-github-bot
Copy link

hibernate-github-bot bot commented Jul 23, 2021

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

@gbadner gbadner marked this pull request as draft July 23, 2021 23:56
@gbadner gbadner changed the title HHH-14744 : Refactor contextual information for SchemaManagementTool … HHH-14744 : Refactor contextual information for SchemaManagementTool to be more easily extended by Hibernate Reactive Jul 23, 2021
@gbadner gbadner requested review from gavinking and dreab8 July 24, 2021 00:09
@gbadner
Copy link
Contributor Author

gbadner commented Jul 30, 2021

I rebased main and force-pushed.

gbadner added 4 commits August 2, 2021 21:51
…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
@gbadner gbadner requested review from Sanne and removed request for gavinking August 3, 2021 04:53
@gbadner
Copy link
Contributor Author

gbadner commented Aug 3, 2021

I added some Javadoc and some other minor changes to be more consistent with DatabaseMetaData methods.

I also force-pushed.

@gbadner gbadner marked this pull request as ready for review August 3, 2021 04:55
@gbadner
Copy link
Contributor Author

gbadner commented Aug 3, 2021

@Sanne, I've added you as a reviewer in case @dreab8 is not available.

@Sanne
Copy link
Member

Sanne commented Aug 3, 2021

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.

@gbadner
Copy link
Contributor Author

gbadner commented Aug 3, 2021

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 @Incubating. I wasn't thinking of Quarkus though. I'll check out Quarkus code so I can keep it on my radar as a consumer in the future. I'm happy to look into how Quarkus uses the SchemaManagementTool currently, if it would save you some time. Please let me know if I should go ahead and do that.

@Sanne
Copy link
Member

Sanne commented Aug 3, 2021

@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.

@gbadner
Copy link
Contributor Author

gbadner commented Aug 3, 2021

@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.
@gbadner
Copy link
Contributor Author

gbadner commented Aug 4, 2021

I just pushed a minor change in Javadoc..

@Sanne
Copy link
Member

Sanne commented Aug 4, 2021

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 SchemaUpdateTest ?

@gbadner
Copy link
Contributor Author

gbadner commented Aug 5, 2021

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 SchemaUpdateTest ?

@Sanne, actually, it looks like the PostgreSQL10Dialect#buildIdentifierHelper can be removed now that HHH-13788 is fixed. I'll check that.

PostgreSQL10Dialect#getNameQualifierSupport was added because the DatabaseMetaData is not available, and ORM's default (NameQualifierSupport.BOTH) is incorrect.

PostgreSQL10Dialect#getSequenceInformationExtractor was added because the default (SequenceInformationExtractorLegacyImpl.INSTANCE) doesn't work for Hibernate Reactive. PostgreSQL stores the sequence metadata as strings. PostgreSQL's JDBC driver does the
conversion from String to Long automatically, but, unfortunately Vert.x driver does not do this conversion.

PostgreSQL10Dialect#getCurrentSchemaCommand was added because Connection#getSchema is not available in Hibernate Reactive.

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 PostgreSQL9Dialect.

@gbadner
Copy link
Contributor Author

gbadner commented Aug 5, 2021

I added @GeneratedValue to the IDs in SchemaUpdateTest just so that I could step through JDBC code that processes the sequences in the debugger so I could better understand why SequenceInformationExtractorLegacyImpl wasn't working with Hibernate Reactive.

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.
@gbadner
Copy link
Contributor Author

gbadner commented Aug 5, 2021

I just pushed a commit that removes PostgreSQL10Dialect#buildIdentifierHelper, since it's no longer needed.

schemaFilter,
tableName.getTableName().getText(),
false, // DO NOT limit to just unique
true // DO require up-to-date results
Copy link
Contributor Author

@gbadner gbadner Aug 10, 2021

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor Author

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
@gbadner
Copy link
Contributor Author

gbadner commented Aug 13, 2021

@Sanne, I've added a commit that moves a couple of methods from PostgreSQL10Dialect into PostgreSQL81Dialect. I verified those methods would work in that dialect by looking at the JDBC source code for PostgreSQL 8.1: https://github.com/pgjdbc/pgjdbc/tree/REL8_1_STABLE.

I also restored SchemaUpdateTest by removing @GeneratedValue annotations.

I will ask about updating io.vertx.sqlclient.Tuple#getLong to do the conversion if the value is a String (rather than throwing ClassCastException. That way, PostgreSQL10Dialect#getSequenceInformationExtractor and SequenceInformationExtractorPostgresSQLDatabaseImpl could be removed.

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
@gbadner
Copy link
Contributor Author

gbadner commented Aug 13, 2021

I was able to fix this in ResultSetAdapter, so I've removed SequenceInformationExtractorPostgresSQLDatabaseImpl and PostgreSQL10Dialect#getSequenceInformationExtractor in a new commit.

@gavinking
Copy link
Member

moves a couple of methods from PostgreSQL10Dialect into PostgreSQL81Dialect.

We should reproduce those changes in H6 I guess.

Actually, eventually we're going to have to replicate all this work across.

@gbadner
Copy link
Contributor Author

gbadner commented Aug 16, 2021

@Sanne, can this be merged?

…to be more easily extended by Hibernate Reactive

Add MySQLDialect#getNameQualifierSupport
@gbadner
Copy link
Contributor Author

gbadner commented Aug 16, 2021

I've added a commit that is required for MySQL. I checked that the setting returned by MySQLDialect#getNameQualifierSupport is correct in MySQL 5.0. MySQLDialect is deprecated, and the oldest subclass is MySQL5Dialect, so this should be fine.

FYI, #buildIdentifierHelper was also added to MySQLDialect.

…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.
@gbadner
Copy link
Contributor Author

gbadner commented Aug 17, 2021

I just added a commit that:

  1. Adds CockroachDB192Dialect#getNameQualifierSupport and #buildIdentifierHelper.
  2. Changes semantics for AbstractInformationExtractorImpl#processIndexInfoResultSet to be more friendly to subclasses.

Copy link
Member

@Sanne Sanne left a comment

Choose a reason for hiding this comment

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

Thanks @gbadner !

@Sanne
Copy link
Member

Sanne commented Aug 25, 2021

I'll merge this soon but would prefer to branch first.

@Sanne
Copy link
Member

Sanne commented Aug 25, 2021

Merging this in ORM 5.6 (current main)

@@ -566,6 +567,11 @@ public JDBCException convert(SQLException sqlException, String message, String s
};
}

@Override
public NameQualifierSupport getNameQualifierSupport() {
return NameQualifierSupport.CATALOG;
Copy link

@yodous yodous Dec 14, 2021

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)

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.

5 participants