Adding support for InterSystems IRIS dialect

[bdeboe]

This Pull Request adds DDL files generated for the new InterSystems IRIS dialect recently added to SqlRender per OHDSI/SqlRender@e5463e2, to address #716

[bdeboe]

The additional unit tests (off by default per the testDatabases <- c("postgresql") in setup.R) rely on the following environment variables:

CDMDDLBASE_IRIS_URL
CDMDDLBASE_IRIS_USER
CDMDDLBASE_IRIS_PASSWORD
CDMDDLBASE_IRIS_CDM_SCHEMA

I can provide values for these to reach our test server through email to the repo admin if needed, though this whole thing is pending a PR for the OHDSI/DatabaseConnector repo.

[bdeboe]

OHDSI/DatabaseConnector#302 was just approved and is now part of DatabaseConnector 6.4. Hopefully that means this PR can now also proceed?

[clairblacketer]

Thanks @bdeboe. Can you confirm that there is an OHDSI iris testing environment?

[bdeboe]

yes, I passed the connection details on to @schuemie a month or so ago for inclusion in the DatabaseConnector test suite.
Do you also want to include IRIS in the CDM regression tests? If so, what kind of schema/database setup would you like (I assume something independent of what the DatabaseConnector tests would see). I can set that up and send you the details through email.

[schuemie]

We have the following secrets set for testing in the OHDSI GitHub organization:

• CDM_IRIS_CDM_SCHEMA
• CDM_IRIS_CONNECTION_STRING
• CDM_IRIS_OHDSI_SCHEMA
• CDM_IRIS_PASSWORD
• CDM_IRIS_USER

I guess we need an empty schema for testing the DDL? Else we could use CDM_IRIS_OHDSI_SCHEMA

[bdeboe]

Schemas don't need to be created upfront in IRIS, so you can use anything you prefer that wouldn't get in the way of DatabaseConnector's use of the database (which I believe will use the contents of the CDM_IRIS_CDM_SCHEMA env variable / secret). I could also create a separate database (with its own connection string) that'd offer more isolation, but that's probably overkill if we just pick a separate schema name.

[schuemie]

If we use CDM_IRIS_CDM_SCHEMA that will conflict with the existing tables in that schema which are used for unit testing by other packages, right?

Are you saying we could create a new schema on the fly just for testing the DDL?

[bdeboe]

that is correct.

-- this should just work:
CREATE TABLE MyNewSchemaForMarch12.COHORT ...;

-- and this is probably a good idea at the end
DROP SCHEMA MyNewSchemaForMarch12;

[schuemie]

Thanks! Could you modify the PR to reflect these changes and use the secrets as specified?

[clairblacketer]

Thank you @schuemie and @bdeboe! @katy-sadowski will work on adding this to our testing structure

[katy-sadowski]

@bdeboe @clairblacketer i have the tests working locally. @bdeboe , can you please grant me push access to your fork so i can open a PR?

[bdeboe]

@katy-sadowski apologies for the very late response, this got snowed under while I was travelling. Should be done now.
LMK if you want me to refresh our fork first or would take care of that as part of your push?

[katy-sadowski]

hi @bdeboe thanks! it'd be best if you refresh, just in case any additional changes need to be made as part of doing that. please let me know when that's complete and i'll push up my changes.

[bdeboe]

Hi @katy-sadowski , merging from the main CDM repo went smoothly

[katy-sadowski]

@bdeboe here is my PR to the Intersystems repo: https://github.com/intersystems-community/OHDSI-CommonDataModel/pull/2/files. feel free to merge it in if it looks OK.

of note, the postgresql testthat tests are failing locally for me, potentially due to an issue with the secrets i have in my env file. let's see if they work when GH Actions runs them.

[bdeboe]

all merged now, thanks @katy-sadowski !

@clairblacketer , do you think this is now ready for inclusion in the main CDM repo?

[katy-sadowski]

It looks like the GH Actions tests passed :) I'm not familiar with Codespell but it looks like a spell checker - guessing we can probably ignore that one.