ParentSemanticPath in AdvancedSearch suddenly changed

  • 4
  • Question
  • Updated 2 weeks ago
Until very recently, the ParentSemanticPath field in Advanced Simple Search and Advanced Search results was returning what it should: the names of the parent folders. Within the last day or so, it suddenly started returning a mixture of GUIDs and actual folder names.

What could cause ParentSemanticPath to contain IDs instead of folder names?
Photo of Erik

Erik

  • 3 Posts
  • 3 Reply Likes

Posted 1 month ago

  • 4
Photo of Adrien Gaillard

Adrien Gaillard

  • 4 Posts
  • 0 Reply Likes
Hi Erik,
I've got the same problem here.
Have you found a workaround?
Thanks

(Edited)
Photo of danziggy

danziggy

  • 1 Post
  • 1 Reply Like
We are also experiencing this issue, with roughly the same timeframe described in the original post.

Still would like to see a response from ShareFile, but thought I'd also add that you can get an individual file's semantic path through the "Get Items by ID" endpoint (GET /sf/v3/Items(:id)) endpoint, with the query param:

{ "$expand": "SemanticPath" }
(Edited)
Photo of Leo

Leo, Official Rep

  • 428 Posts
  • 41 Reply Likes
Hi everyone,

We're aware of the change and are looking into it.  Unfortunately I do not have any other information at this time.

-Leo
Photo of Erik

Erik

  • 3 Posts
  • 3 Reply Likes
We continue to have problems with this -- as a workaround, we are generating extra API calls to look up the name of any folder that is returned as an ID, which is obviously sub-optimal.

We tried a workaround of switching to the Search endpoint instead of AdvancedSimpleSearch, but this was returning a radically incorrect number of results (on the order of 15 files returned when there should have been 200), so we abandoned this strategy. Does anyone know why Search would return an incorrect number of results?

For that matter, it seems AdvancedSimpleSearch itself is now failing to return items it should _definitely_ be finding, though it does better than Search (on the order of 170 files returned when there should have been 200).

We're very disappointed with ShareFile's responsiveness on these issues. While we can work around the inconsistency in ParentSemanticPath, the fact that we can't even trust search results to be complete is unacceptable.
(Edited)
Photo of Adrien Gaillard

Adrien Gaillard

  • 4 Posts
  • 0 Reply Likes
Hi Erik,
yes, the AdvancedSimpleSearch is full of bugs.
There are missing files when using the creation start date option.
This bug has been known for more than a year...
Photo of Erik

Erik

  • 3 Posts
  • 3 Reply Likes
Interesting that something this fundamental has been broken for so long.

I'm not using creation start date and it still appears broken to me. All I need is a way to get the ID of every file within a folder recursively (ie including subfolders). I don't care about creation date or any other parameters, I just want all the files in a folder. Is there another way to accomplish this? It would be very surprising to me if there was no reliable way to list files within a directory.

If ShareFile can't manage to list files within a folder reliably, we'll have to change vendors.