Forum Discussion
SharePoint Search API response schema changes
Hi, I've started noticing issues with search REST api results lately where there are some new properties returned in the schema and some null values.
Ex: _api/search/query?querytext='Filename:B315N1001A.dwg AND ParentLink:106982_P'&selectproperties='Filename,DefaultEncodingURL,SPSiteUrl,UniqueID'&sortlist='LastModifiedTime:descending'
Returned values with Null (these values where never null before)
"Key": "PartitionId",
"Value": null,
"ValueType": "Null"
},
{
"Key": "Culture",
"Value": null,
"ValueType": "Null"
},
New properties that where never there before:
{
"Key": "DocumentSignature",
"Value": "-XXXXXX;-XXXXXX;-XXXXXX;-XXXXXX",
"ValueType": "Edm.String"
},
{
"Key": "CollapsingStatus",
"Value": "0",
"ValueType": "Edm.Int32"
}.
This is causing issues with my json parsing schema.
Any info on this?
- My take is this. You should only expect properties you ask for. These may or may not have values depending on the property. As such, you should not have a rigid schema to validate returned data.
DocumentSignature/CollapseStatus are by no means new ones. As for other props these can and will change as we make changes. And the schema contract is a weak one and you should only count on any public documented properties or those you have created yourself.
Hope this makes sense 🙂
- UPDATE: I'll have to validate but the collapsingStatus and DocumentSignature do not seem to be always returned so I need to understand why.
However, having the Culture and PartitionId set to null does not seems to be valid...- No help Martin but i am also having problems since 30th with extra properties in schema, order of properties returned changing and previously valid search queries no longer filtering
I am facing the very same issue that results in failure of Json parsing. Is there any update from microsoft on this issue.
Here are some findings in the results I'm getting. I've updated my power automate json schema (now I will always put things like "anyOf": ["type": "string", "type": "null"] in my schema definition) but I'm worried about the impact of these types of changes as I'm building flows for a lot of customers...:
RelevantResults.Properties
Removed
â—‹ GenerationId
â—‹ indexSystem
â—‹ GeoLocationSource
Table.Rows.Cells
Changes
UniqueID:
Before Example: "Value": "36b8e7c3-deb7-42a2-89bf-551ccbbab779"
Now : "Value": "{36b8e7c3-deb7-42a2-89bf-551ccbbab779}"
PartitionId
Before Example: "Value": "a348e418-3879-46f3-b30e-c4bc1eaca908", "ValueType": "Edm.Guid"
Now: "Value": null, "ValueType": "Null"
Culture
Before Example: "Value": "fr-FR","ValueType": "Edm.String"
Now: "Value": null, "ValueType": "Null"
MikaelSvensonMicrosoft
My take is this. You should only expect properties you ask for. These may or may not have values depending on the property. As such, you should not have a rigid schema to validate returned data.
DocumentSignature/CollapseStatus are by no means new ones. As for other props these can and will change as we make changes. And the schema contract is a weak one and you should only count on any public documented properties or those you have created yourself.
Hope this makes sense 🙂- Hi Mikael, I agree and that is what I've done to fix my schema parsing. However I'm wondering why results properties like Culture is now returning null. Is this an issue?
Thanks.
