-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SqlIntegrityConstraintViolationException while using multiple data sources together #639
Comments
Assuming I'm right: What we're losing: in past you could configure a single "default" datastore in the "default" tenant and then serve multiple different tenants (each with their own config) from that one datastore. |
I think the above should read: "After this change, EACH tenant will need to create its own datasource in their own config." I agree - it makes it more explicit, and tenants should be completely isolated. |
… default Signed-off-by: Robin Arnold <robin.arnold23@ibm.com>
issue #639 datasources must come from tenant config, not fall back to…
The tests seem to adequately cover this change |
Describe the bug
While working on the db2 integration tests, I decided to used db2 for the
default
tenant, but keeptenant1
using derby so that we don't need to deploy the schema 4 times.Unfortunately, this caused an issue in our integration tests. When the MultiDataStoreTest invokes a reequest with tenant=tenant1 and datastore=default, the config helper falls back to the default tenant config and so we end up using the db2 connection from default/default and that leads to:
To Reproduce
Steps to reproduce the behavior:
MultiDataStoreTest.testCreateObservation()
and changestudy1
todefault
build/pre-integration-test-docker.sh
to setup up the fhir+db2 compose envExpected behavior
The tenant1 requests should fallback
Additional context
Should we allow this kind of multi-database setup? What datasource should we use for the "admin" schema in these cases?
Can we use that one for the resource name cache so we don't get these conflicts?
If not, can we make the resource name cache tenant-specific?
Will our other caches have the same issue?
The text was updated successfully, but these errors were encountered: