Structured metadata pseudo-array using "string" with comma-delimited data

pludlow
pludlow Member Posts: 17
edited April 2023 in Developer APIs

My company has need of an array type field for structured metadata. This currently doesn't exist as an option for "Cloudinary Assets" (formerly DAM). To address this need, I have been given the recommendation to use a string type and have the value be a comma-delimited set of data. This seems to work, but there are some odd behaviors with queries in this approach.

For my example, I have 5 images using a metadata string field with comma delimited values:

  1. 1,2,3,4,5,6,7,8,9
  2. 15,111,2,1
  3. 11,22,101
  4. 115
  5. 101,102,103,1111

If I use Advanced search in the UI on this field to query when the value contains 1, then I get the three results of: #1, #2, and #3 (which doesn't seem to make sense because I'd expect two or all five). The UI query for this is: (metadata.field:"1*")

Similar unexpected behavior appears if I search (metadata.field:"11*") where I get two results instead of only one that I would want (even three results would be understood although I don't want that many).

However, if I manually change the query and remove the wildcard to (metadata.field:"1") I get the two correct expected results of #1 and #2. However, I can't do an UI Advanced search for this query because the most relevant option is "equal to" and makes a query of (metadata.field="1") which gives no results. This can be corrected in Query Builder however.

Is my understanding of these behaviors correct, and the proper method to use? My company is about to undergo a major migration of content from our legacy system and will translate array type fields to Cloudinary using this approach. If there is a better option I'd love to hear about it.

Ideally I would like an array type option for Structured Metadata, but that may never happen or would not happen any time soon. "Tags" behavior is what we are looking for, but not as a general tags field, and instead targeted to a specific metadata field. We can't use a set because it is impossible or extremely difficult to manage set members of all possible strings that could be added (think numbers or IDs).

If anyone has done something like this, please respond oh what you did.

Thanks.

Tagged:

Comments

  • aleksandar
    aleksandar Member, Cloudinary Staff Posts: 14

    Hi Phil,

    Your understanding is indeed absolutely correct.

    As you noted, the Advanced Search UI chips do have the option of supporting "Equal to" which will result in an `exact search` (`=`) e.g. `metadata.field="1"` on the metadata value - but that won't return you the results since it'll try to match it against the entire metadata field value which wouldn't match based on your examples.

    Using the Query Builder, you do get the expected results when using `metadata.field:"1"` (`token search`) however this option isn't available in the UI.

    I will check internally if there are plans to add this functionality under the UI chips so that instead of an `Equal to` there is another option that in the background uses a token search (`:`) rather than exact search (`=`).

    If your users will be primarily searching via the UI then it is possible to create a search for `metadata.field:"1"` and save that as a "Saved Search" - which then your account's users will have access to search with via a few clicks. Users can select a saved search from the "Saved Searches" section under the "Search Modes" and they would only need to change the number/ID in the query to search based on their requirements.

    If you're searching via the API, then you can make the token search (`metadata.field:"1"`) directly in the `expression` field.

    Best,

    Aleksandar

  • pludlow
    pludlow Member Posts: 17

    Thanks for the reply. This confirms my thoughts.

    I think most queries of this type will be done by API so those services will just use the proper expression. However, I will likely make a custom search in the UI for instances when a user may need to do a token search.

    Thanks for your help.