Skip to content
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

Make conditional_create_duplicate_identifiers_enabled default true if partitioning is enabled #6442

Open
esecules opened this issue Nov 5, 2024 · 1 comment

Comments

@esecules
Copy link

esecules commented Nov 5, 2024

NOTE: Before filing a ticket, please see the following URL:
https://github.com/hapifhir/hapi-fhir/wiki/Getting-Help

Describe the issue
One of the requirements for data partitioning and multitennancy is that one tenant's data cannot affect another tenant. However the default setting: conditional_create_duplicate_identifiers_enabled=false means that Resource identifiers must be globally unique across tenants (see error message below). This is not expected when partitioning is enabled. I propose that this setting is default true when partitioning is enabled so that identifiers from separate tenants can have the same values. I might go one step further to suggest that this setting is not needed at the top level as I cannot see a case where we would want to set it to true or false independently of enabling or disabling partitioning as a whole.

Environment (please complete the following information):

  • HAPI FHIR Version
  • OS: [e.g. iOS]
  • Browser [e.g. chrome, safari]

Additional context
The default configuration for partitioning produces this error log when I run my partitioning tests that create two identical resources in two separate tenants. I would expect that partitioning works by default.

ERROR: duplicate key value violates unique constraint \"hfj_res_search_url_pkey\"\n  Detail: Key (res_search_url, partition_id)=(Patient?identifier=1_76, -1) already exists.
@esecules
Copy link
Author

esecules commented Nov 5, 2024

relates to the setting added in #5983 to fix the bug #6033

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant