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

Use drop scripts to cleanup,validate quartz tables #1573

Merged
merged 2 commits into from Dec 17, 2019

Conversation

gmunozfe
Copy link
Member

@gmunozfe gmunozfe commented Dec 5, 2019

Fixing tests for most of the databases (still pending db2 and sybase, only for upgrading scripts) in the community-tests-jbpm-db-matrix pipeline.

  • Instead of delegating in hibernate hbm2ddl to drop constraints and tables, tests now are invoking drop scripts and hence, these scripts are tested too.

  • Removed tests with hbm2ddl.auto "create-drop" or "update", as constraint hashes generated by Hibernate are now different than those coming from the DDL scripts (kept these for backward compatibility).

  • In some upgrade-scripts, there were incorrect delimiters and syntax that have been fixed.

  • Added support for new dialect SybaseASE157Dialect; this change also implies modification in the sybase-jbpm-schema.sql because this dialect (the latest for sybase) is overriding
    registerColumnType( Types.BIGINT, "bigint" );
    instead of SybaseDialect that keeps:
    registerColumnType( Types.BIGINT, "numeric(19,0)" );
    Therefore, for right validation, it's needed to switch in the script the type "numeric(19,0)" to "bigint".

  • Added new sql Quartz drop scripts to handle dropping through these files, and keep the database cleaned at the end of the tests.

  • Quartz tables are now also validated with the hdm2ddl validate strategy and using mocked Quartz entities and a new persistence unit dbQuartzValidate. Hence, we make sure the JPA entity mapping schema is in sync with the database one (as it's done with jBPM tables).
    Entity classes define the mapping for all databases, therefore, to keep the scripts as they are, some tuning has been needed for validating through custom dialects.
    This persistence unit does not delegate into maven dialect property (as for jBPM tables), but a new dialect resolver "resolves" the custom dialect which overrides some mappings SQL-java. For example, for the boolean type, there are Quartz scripts defining it as varchar (mysql, sql server and oracle), bit (sybase) or integer (db2). Even db2 defines both -varchar and integer- that's the reason of keeping just one of them for correct mapping.

Copy link
Member

@MarianMacik MarianMacik left a comment

Choose a reason for hiding this comment

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

Finally went over it. Very good job! I would be interested mainly where you found that Hibernate Dialect adaptation because I found almost nothing when I tried to find it on the web.

There are some comments, just to be sure I am on the same page as you are.

BOOL_PROP_1 VARCHAR(1),
BOOL_PROP_2 VARCHAR(1),
BOOL_PROP_1 INTEGER,
BOOL_PROP_2 INTEGER,
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 if this is backward compatible, I mean if somebody will try to migrate data from one DB to the newly created DB. I presume these scripts shouldn't be changed as they come directly from Quartz?

Copy link
Member Author

Choose a reason for hiding this comment

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

In the quartz db2 schemas (tables_db2 and tables_db2_v72) boolean are mapped always to varchar(1). This is different for schemas (tables_db2_v8, tables_db2_v95), where SQL boolean type is mapped into:

  • varchar(1) for BOOL_PROP_1, BOOL_PROP_2 at qrtz_simprop_triggers table
  • integer for is_durable, is_nonconcurrent, is_update_data, requests_recovery at qrtz_job_details table and is_nonconcurrent, requests_recovery at qrtz_fired_triggers table.

Now I've unified like in tables_db2, but if you don't feel comfortable because this change is not backward-compatible, I can leave it as it was (db2 is already failing for upgrading scripts)

DROP TABLE IF EXISTS QRTZ_TRIGGERS;
DROP TABLE IF EXISTS QRTZ_JOB_DETAILS;
DROP TABLE IF EXISTS QRTZ_CALENDARS;

Copy link
Member

Choose a reason for hiding this comment

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

Although this is backward-compatible, I think it would be good to mention in release notes or in documentation in general that drop scripts were introduced, meaning that if previously drop commands were a part of normal scripts, now they are in a separate file.


public MySQLCustomDialect() {
super();
registerColumnType(Types.BLOB, "blob");
Copy link
Member

Choose a reason for hiding this comment

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

This is for DDL to properly validate the type?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, it assigns the "blob" from the script to the sql code of hibernate for managing BLOB

@Override
public SqlTypeDescriptor remapSqlTypeDescriptor(SqlTypeDescriptor sqlTypeDescriptor) {
if (sqlTypeDescriptor.getSqlType() == java.sql.Types.BLOB) {
return BinaryTypeDescriptor.INSTANCE;
Copy link
Member

Choose a reason for hiding this comment

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

Why is this change needed?

Copy link
Member Author

Choose a reason for hiding this comment

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

In fact, this is not needed, removed

@Override
public void contributeTypes(TypeContributions typeContributions, ServiceRegistry serviceRegistry) {
super.contributeTypes(typeContributions,serviceRegistry);
typeContributions.contributeType(new Boolean2Varchar());
Copy link
Member

Choose a reason for hiding this comment

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

Couldn't we just remap the SQLTypeDescriptor? If I understand it correctly, when Hibernate finds a boolean field, it then converts this using the standard org.hibernate.type.BooleanType class, which has this( org.hibernate.type.descriptor.sql.BooleanTypeDescriptor.INSTANCE, BooleanTypeDescriptor.INSTANCE ); as SQL type descriptors and Java type descriptors. By remapping the sql descriptors we would just remap Boolean one to the Varchar one and we don't need the custom Boolean2Varchar class. Wdyt?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, you're right, we can register it as:
registerColumnType(Types.BOOLEAN, "varchar(1)");
and those classes (Boolean2Varchar, etc.) are not needed

@gmunozfe
Copy link
Member Author

@MarianMacik I've gone through all your comments, thanks a lot for your review!

testIsInitialized();
final File[] sqlScripts = TestsUtil.getDDLScriptFilesByDatabaseType(scriptsRootFolder, databaseType, true);
final File[] sqlScripts = TestsUtil.getDDLScriptFilesByDatabaseType(scriptsRootFolder, databaseType, true, dropFilesExcluded);
if (sqlScripts.length == 0 && databaseType!=DERBY && dropFilesExcluded) {
Copy link
Member

Choose a reason for hiding this comment

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

So what if there are no drop scripts, are we OK with that?

Copy link
Member

@MarianMacik MarianMacik left a comment

Choose a reason for hiding this comment

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

Looks good. I am glad that we don't have to invent custom types now :)

@gmunozfe
Copy link
Member Author

After looking at ddl60 drop scripts, we cannot remove them: they are needed because the constraint hashes for 6.0 are different than 7.x; therefore, we need to drop these constraints with its proper name before dropping the table, because some of them are foreign keys: h2, derby and oracle don't need this, that's the reason of missing drop scripts in their ddl60 folders, and that's why I was only checking the list of scripts were not null for "create" scenarios (not drop).

Copy link
Member

@MarianMacik MarianMacik left a comment

Choose a reason for hiding this comment

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

Just one question, otherwise looks very good!

@MarianMacik
Copy link
Member

jenkins retest this

@gmunozfe
Copy link
Member Author

jenkins retest this

@MarianMacik
Copy link
Member

@sutaakar can you look at it as well? We are green, but just to have another pair of eyes :)

@sutaakar
Copy link
Contributor

Briefly checked.

@MarianMacik MarianMacik merged commit 2504404 into kiegroup:master Dec 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants