Only that you should not be making any custom additions to the WebAPI schema, as this will possibly conflict with future DDL migrations in new versions of WebAPI. Referring tho this:
Update: in reading this more closely, it looks like you are adding a FK to a CDM table CDM_SOURCE and the CDM Table CONCEPT. The schema you referenced was ‘webapi’ which is confusing because webapi schema is not a CDM.
Next, it’s clear that the connection to the CDM DB (with the results schema) is failing: password authentication failed for user ‘ohdsi_admin’. While other things may appear to be working in Atlas, Atlas (WebAPI specifically) is using the credentials defined in your settings.xml to connect to the web API database, and will only use the SOURCE tables when trying to connect out to your CDM source. They may be one-in-the-same, but the connection details are coming from differnt places.
No, as referenced above, settings.xml is where WebAPI finds the connection information to the WebAPI database. The datasource ohdsi schema is the schema where WebAPI tables live, and naming it ‘cdm’ would be extremely confusing.
As stated in several other threads: while it’s possible to put your WebAPI and CDM into the same database (this may be the way broadsea sets it up as a simple starting point), I’ve argued that this is not the optimal configruation because you should have a clean separation between databases and their purpose: there is one WebAPI database, there are one or more CDM databases. The WebAPI uses credentials for genaral operations and another for DB migration work (flyway.datasource.* settings). The CDM database contains a CDM scheama (that you ETL’d your source data from), a results schema (that Achilles writes into, and WebAPI provides DDL to create additional tables), and the credentials to connect to this database is in the SOURCE table.
I’d suggest you make a logical diagram of your datasource, with a box for your WebAPI server (tomcat?), a box for your postgres database that hosts WebAPI tables, a box for each of your CDM sources, and draw lines between the boxes indicating where the credentaials are comming from (the WebAPI service box to WebAPI database comes from settings.xml for exaple). But make this diagram to reflect your own environment. Then you will have a clear picture of where servers are living and how they are connecting to each other, which may help you isolate where the problem lives.
In addition, you should check your WebAPI logs for errors, it’s likely that if your R session is getting a auth failure, and it is the same credentails in your Source table, then you should probably see the same auth failure in the WebAPI logs.