NIFI-8831 Support using MSSQL as nifi registry relation database engine

[nathluu]

Summary

NIFI-8831

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using mvn clean install -P contrib-check
  • JDK 11
  • JDK 17

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[bbende]

In general I think the application shouldn't really be checking the type of database, with the exception of the Flyway stuff that sets up the DB. It is not clear to me what the different SQL here is doing, but can it be done in a general way that conforms to standard SQL?

[nathluu]

Because IDENTITY is a keyword in MSSQL but not on H2, mysql, mariaDB and postgresql so for MSSQL it must be enclosed by [].

[ChrisSamo632]

Suggested change

	: "INSERT INTO UGP_USER(IDENTIFIER, IDENTITY) VALUES (?, ?)";
	final String sql = "INSERT INTO UGP_USER(IDENTIFIER, \"IDENTITY\") VALUES (?, ?)";

Consider escaping with double quotes instead, which is the ANSI/ISO standard, so hopefully works across all supported database types

[nathluu]

Hi @ChrisSamo632,
I tried your suggestion on branch nathluu/registry-mssql-b but it does not work.
Caused by: org.springframework.jdbc.BadSqlGrammarException: PreparedStatementCallback; bad SQL grammar [INSERT INTO UGP_USER(IDENTIFIER, "IDENTITY") VALUES (?, ?)]; nested exception is java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"IDENTITY") VALUES ('76137000-a35a-3bb2-94d7-2f5bac309242', 'CN=user2, OU=nifi')' at line 1
at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:239)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:70)
at org.springframework.jdbc.core.JdbcTemplate.translateException(JdbcTemplate.java:1541)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:667)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:960)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:1015)
at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:1025)
at org.apache.nifi.registry.security.authorization.database.DatabaseUserGroupProvider.addUser(DatabaseUserGroupProvider.java:133)
at org.apache.nifi.registry.security.authorization.database.DatabaseUserGroupProvider.onConfigured(DatabaseUserGroupProvider.java:97)
at org.apache.nifi.registry.security.authorization.AuthorizerFactory.getAuthorizer(AuthorizerFactory.java:191)

[ChrisSamo632]

ANSI Mode would need to be enabled for MySQL - see https://stackoverflow.com/questions/2889871/how-do-i-escape-reserved-words-used-as-column-names-mysql-create-table/2889884#2889884, otherwise backticks would be necessary to escape column names of any reserved/keywords we're used in MySQL (I guess IDENTITY isn't such a word for existing supported DBs but is for MSSQL)

If we were to start requiring that mode to be set (I don't know whether other database types have similar settings) then document updates would be a good idea, but arguably this becomes a potentially breaking change for some users

Renaming the column to avoid keywords is another option, but again incompatible with existing deployments

I don't know which would be the preferred approach in that case. Maybe @bbende will have a preference

[exceptionfactory]

Thanks again for the work on this feature @nathluu. Based on the discussion, I created a new Jira issue NIFI-12059 describing a general need for Registry framework adjustments, along with a potential solution. Once such a solution is in place, then we should be in a better position in implement support for additional database vendors, so I'm closing this pull request for now.