Discrepancy in cohort_inclusion_results table definitions

[MaximMoinat]

The cohort_inclusion_result table is created differently depending on how you set up your results schema.

The WebApi sets up this table using this outdated definition: https://github.com/OHDSI/WebAPI/blob/60ef67fd31bfc8fcd7e46c3b71bc3f42566282ef/src/main/resources/db/migration/postgresql/V1.0.2.0__cohort_feasiblity.sql#L9-L13

The new DDL uses the new definition, expected by Atlas v2.7: https://github.com/OHDSI/WebAPI/blob/60ef67fd31bfc8fcd7e46c3b71bc3f42566282ef/src/main/resources/ddl/results/cohort_inclusion_result.sql#L2-L7

If you choose to use the same schema for the WebApi and the results, then this clashes as the newer definition is not used. The simple solution is to use two separate schemas. Still it would be good if the WebApi db definition is updated to either not create cohort_inclusion_result at all or use the new definition.

Thanks. And happy holidays! 🎄

[anthonysena]

Hi @MaximMoinat - I'd note here that setting up the results schema is done by following the steps on the wiki: https://github.com/OHDSI/WebAPI/wiki/CDM-Configuration#results-schema-setup. Following those instructions will use the proper WebAPI/src/main/resources/ddl/results/cohort_inclusion_result.sql that you mentioned in the issue.

The other script you pointed out is an older Flyway script that is used to update the internal WebAPI database - that script really should not create the cohort_inclusion table in the WebAPI DB since it is not used. The challenge here is that it is not a good practice to revise historical Flyway migrations - we could add a migration to drop that table from WebAPI but then we'd have 3 references to that table. This will be something we clean up as part of the Atlas/WebAPI 3.0 work for next year.

Happy holidays to you too! I'm going to close this out but please re-open if you have any further questions.