Stream: hapi

Topic: Unique search parameter constraint applied across partitions

Pengyu Wang (Jul 13 2021 at 06:15):

Background

I have created a search parameter on the patient resource to guarantee uniqueness on the patient identifier, thus preventing race conditions when bulk inserting resources. See original post here.

However, I noticed during testing that the uniqueness constraint is applied across all partitions (I have partitioning enabled on the server). Here are theSearchParameters I created:

{
    "resourceType": "SearchParameter",
    "id": "1",
    "title": "Unique Identifier",
    "name": "PatientUniqueIdentifier",
    "status": "active",
    "code": "uniquePatientIdentifier",
    "base": [
        "Patient"
    ],
    "type": "token",
    "expression": "Patient.identifier.where(system='external-patient')"
}

{
    "resourceType": "SearchParameter",
    "id": "2",
    "extension": [
        {
            "url": "http://hapifhir.io/fhir/StructureDefinition/sp-unique",
            "valueBoolean": true
        }
    ],
    "status": "active",
    "code": "patient-identifier",
    "base": [
        "Patient"
    ],
    "type": "composite",
    "expression": "Patient",
    "component": [
        {
            "definition": "SearchParameter/1",
            "expression": "Patient"
        }
    ]
}

Expected behavior

I should only be able to create one patient with identifier 123 in PARTITION-1, but I can also create a patient with the same identifier in PARTITION-2.

Actual outcome

When I create a patient with identifier 123 in PARTITION-1, it works. But when I try to create a patient with the same identifier in PARTITION-2, I got an error saying The operation has failed with a unique index constraint failure.. This is not the expected behavior because it may very well be likely that patients in different partitions have the same identifiers.

Investigation

After going through the source code, I believe the issue is here: when querying for existing indexed unique composite strings, it does not take the partition id into account, even though partition_id is a column in the hfj_idx_cmp_string_uniq table.

My questions are:

1. Is this the intended behavior (that the uniqueness constraint should apply across partitions) or is it a bug?
2. How can I get around this issue?

Aaron Kawalsky (Jul 20 2021 at 22:58):

@James Agnew do you know if the above is intended behavior? We are considering putting up a pull request to change unique params to respect partition.

Last updated: Apr 12 2022 at 19:14 UTC