Conflicting Sizes Returned From arcgis.gis.Item

[bixb0012]

I am trying to understand this behavior:

>>> import arcgis
>>>
>>> url = # url of Portal or Organizational AGOL
>>> username = 
>>> password = 
>>> item_name = # name of item for looking up size
>>> 
>>> gis = arcgis.gis.GIS(url, username, password)
>>> item = gis.content.search(item_name)[0] # assumes unique name so only 1 item returned
>>> type(item)
<class 'arcgis.gis.Item'>
>>> item.size
-1
>>> item_full = gis.content.get(item.id)
>>> type(item_full)
<class 'arcgis.gis.Item'>
>>> item_full.size
3850776
>>> 

If I retrieve an item using arcgis.gis.ContentManager.search, I get an arcgis.gis.Item object where the size is returned as -1. If I retrieve the exact same item using arcgis.gis.ContentManager.get, I get an arcgis.gis.Item object where the size is returned as 3850776, which just happens to be the correct size.

If search and get are both returning arcgis.gis.Item objects, why do the results for size differ?

I am going to anticipate a possible response and reply. If the answer is that search doesn't retrieve all of the items properties while get does, then I ask "why not?" And if the response to that is 'performance,' then at a minimum the documentation needs to clearly point this out.

[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