Skip to content

Make non-partitionable resource types configurable instead of hardcoded in BaseRequestPartitionHelperSvc #6875

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.

Sign up for GitHub

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

Jump to bottom
Open
patrick-werner opened this issue Apr 16, 2025 · 2 comments · May be fixed by #6877
Open

Make non-partitionable resource types configurable instead of hardcoded in BaseRequestPartitionHelperSvc #6875

patrick-werner opened this issue Apr 16, 2025 · 2 comments · May be fixed by #6877

Comments

@patrick-werner
Copy link
Member

Problem Description

Currently, HAPI FHIR hardcodes a list of resource types as non-partitionable in the class BaseRequestPartitionHelperSvc:

myNonPartitionableResourceNames.add("StructureDefinition");
myNonPartitionableResourceNames.add("Questionnaire");
// ...

This behavior prevents resource types like Questionnaire from being partitioned, even though many real-world multi-tenant deployments require exactly that (e.g. tenant-specific forms, templates, libraries, etc.).

To override this restriction, developers currently must:

  • Subclass RequestPartitionHelperSvc
  • Use reflection to remove "Questionnaire" from the internal Set
  • Override Spring beans manually – which is brittle and unsupported across versions

This limits flexibility and increases complexity for multi-tenant environments.

Proposed Change

Introduce a first-class extension mechanism (e.g. a setter or protected method) that allows customizing the list of non-partitionable resource types without relying on reflection or deep bean replacement.
@jamesagnew
Copy link
Collaborator

None of the validation infrastructure is currently designed to know how to look in non-default partitions when looking up resources for validation. This change seems simple, but would need to touch the validation support layer (to ensure that we look in the right place - presumably we'd need to start passing RequestDetails down into calls to IValidationSupport in order for the partition service to be able to correctly determine the partition), the cache layer (to ensure that the cache doesn't give up data belonging to one partition to another), and possibly more.

Definitely agree that this would be great, but it's a very major change.

patrick-werner added a commit that referenced this issue Apr 16, 2025
@patrick-werner
feat: enhance partition settings to manage non-partitionable resource…
ed4d9aa 
… types

Closes #6875
@patrick-werner patrick-werner linked a pull request Apr 16, 2025 that will close this issue
Open
@patrick-werner
Copy link
Member Author

None of the validation infrastructure is currently designed to know how to look in non-default partitions when looking up resources for validation. This change seems simple, but would need to touch the validation support layer (to ensure that we look in the right place - presumably we'd need to start passing RequestDetails down into calls to IValidationSupport in order for the partition service to be able to correctly determine the partition), the cache layer (to ensure that the cache doesn't give up data belonging to one partition to another), and possibly more.

Definitely agree that this would be great, but it's a very major change.

Thanks for the reply James. I will try to extend my PR to the needed changes you mentioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: enhance partition settings to manage non-partitionable resourcetypes hapifhir/hapi-fhir
2 participants
@jamesagnew @patrick-werner