OHDSI Home | Forums | Wiki | Github

Updating Atlas cohort defenitions not showing up

Developers
#21

This isn’t the version of WebAPI that is running, it’s a schema version based on which migrations have been executed found in the webapi.schema_version table.

No, we need to let the db migration scripts do their job. If we start working around it, then we will have no predictable state of the db to work off for future migrations.

Case in point: this migration script converted the column from an int to a varchar. So an open question is why your table shows an ‘int’ in that column if you have deployed v2.9 migrations?

We can start to ‘work around’ the migration scripts if it looks like the system thinks it deployed them but the actual schema doesn’t reflect this change. That would be very alarming to me, but I think you’re environment is unique in how the schema seems confused…I’m not sure how it got there, but at this point we can just try to apply patches.

But before we intervene in the webapi schema manually, can you please execute this query and report the output, specifically looking for the V2.7.0.2019031417003_alter-ir-execution-status-as-string migration in the output to see if it was applied and was successful: select * from webapi.schema_version order by installed_rank;

#22

Gotcha that makes sense, I honestly don’t know how things would have gotten messed up without an issue cropping up previously. Looking into how this was all set up (a few years before I arrived at chop) They created a dockerfile and used a specific commit of the web api found here:

I have no idea if this is relevant but wanted to add that is as it may be important.

The results of the query specifically the line you are looking for:

Screen Shot 2022-08-19 at 12.45.30 PM
Screen Shot 2022-08-19 at 12.45.30 PM1742×32 19.7 KB

I attached the results as well:
schema_version_out.xlsx (24.2 KB)

Thanks again.

Best,
Alex

#23

Thanks for the output. The schema migration says that it did it so I am definitely confused (and worried) that the ALTER TABLE did not apply.

Since the migration indicates it did the job, there’s no harm in us apply the same unit of work, and in this case I don’t think there’s any down-stream dependencies on the altering of this table, so, you can go ahead and execute this:

ALTER TABLE ${ohdsiSchema}.ir_execution RENAME status TO int_status;

ALTER TABLE ${ohdsiSchema}.ir_execution ADD status VARCHAR(128);

UPDATE ${ohdsiSchema}.ir_execution SET status = CASE int_status
    WHEN -1 THEN 'ERROR'
    WHEN 0 THEN 'PENDING'
    WHEN 1 THEN 'RUNNING'
    WHEN 2 THEN 'COMPLETE'
    END;

ALTER TABLE ${ohdsiSchema}.ir_execution DROP COLUMN int_status;

Replace the ${ohdsiSchema} with your webapi schema name.

Side question: is there any possiblity that you have multiple webAPI schemas set up and you could be thinking your accessing one but the webapi is actually accessing another?

#24

Okay so I ran that and it looks like it worked finally!!! Thank you so much!

We introduced the ldap auth in this version so I’ll have to go thru and set permissions correctly in order to confirm everything is working correctly.

Thanks again its so greatly appreciated.

Best,
Alex

t