Conflicting Sizes Returned From arcgis.gis.Item about arcgis-python-api

[AtmaMani]

@bixb0012 yes this is a result of optimization in search logic, not by the Python API, but by the REST API. Searching returns results from an index that captures only certain fields and size is not part of it. However when you use get, you query and obtain the full item. Hence the disparity.

After filtering your search result, you could call the _hydrate() method on the item of interest to get its size among other information.

This is not documented because they hydration logic happens transparently to the user when you request for a property that is not initialized.

[bixb0012]

@AtmaMani , thanks for the prompt reply and additional information.

I get what you are saying about the REST API doing the optimization, and why that would be beneficial.

I tried calling _hydrate() and it does do the trick. That said, I am a bit confused with your comment about hydration, not the logic/concept but the results I am seeing. If hydration "happens transparently to the user when you request for a property that is not initialized," why doesn't it happen when I try to retrieve the size initially?

[AtmaMani]

@bixb0012 good point, I anticipated that question from you. Interestingly size property was not uninitialized in the response from portal when you did a search query. Instead, it was set to -1, hence the hydration logic did not kick in when you queried for that property.
I will discuss this over with the portal team and see if the server can drop this key value pair in the JSON response for search query since its not indexed anyway.

[bixb0012]

Any updates from the Portal team? If, for whatever reason the Portal team doubles down on -1, do you think the hydration logic could be updated to trigger with invalid/nonsensical values like -1?

[rohitgeo]

@bixb0012, thanks for the suggestion. We will fix this in the next update.

[AtmaMani]

Fixed in v1.0.1 of arcgis package