Hello,
I had a few questions regarding qualifers in cht-datasource, particularly around @jkuester’s comment and the issue description of #9835.
The description mentions having two qualifiers one for contacts and one for reports.
We had to support and API for reading generic contacts because there are certain application contexts where you have a contact _id value, but do not know if it is a person or place (so you need some way to get the data to check). However, I do not think we should support creating/updating via a generic contacts API. Instead these should be supported via the person and place APIs.
As per this comment, should we add qualifiers for person and place as well such that they would extend/omit some ContactQualifier properties based on the schema and validation rules listed out in @jkuester’s comment?
Also, I do not understand why they are being referred to as “qualifiers”.
My assumption is that they will be the objects we pass to the database for creating/updating documents after validation and appending optional fields like reported_date if they aren’t provided or ensuring type==="contact" if contact_type is set.
Am I missing something?
As per this comment, should we add qualifiers for person and place as well such that they would extend/omit some ContactQualifier properties based on the schema and validation rules listed out in @jkuester’s comment?
Well, if the situation comes when there needs a distinction between place or person when validating then, extending the ContactQualifier interface will be necessary.
Also, I do not understand why they are being referred to as “qualifiers”.
My assumption is that they will be the objects we pass to the database for creating/updating documents after validation and appending optional fields like reported_date if they aren’t provided or ensuring type==="contact" if contact_type is set.
Am I missing something?
The target of these “qualifiers” is to create consistent immutable objects that can be referenced everywhere. It helps during development on what a valid object structure would be and during runtime when the properties need validation. For instance, let’s take a look at the UUIDQualifier. Instead of passing around raw UUID strings, you wrap them in a specific type that makes the code’s intent clearer and provides runtime validation. The type guard allows you to safely check if an unknown value matches this specific identifier format. They are like DTO(Data Transfer Objects) in a sense.
Yes, the qualifiers will be objects that we will be passing around and they can be passed into the database for create and update.