Skip to content

Fix recursive search in Client.get_items #799

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Closed
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.

- Fix usage documentation of `ItemSearch`
- Fix fields argument to CLI ([#797](https://github.com/stac-utils/pystac-client/pull/797))
- Fix recursive search in `Client.get_items` ([#799](https://github.com/stac-utils/pystac-client/pull/799))

## [v0.8.6] - 2025-02-11

Expand Down
23 changes: 15 additions & 8 deletions pystac_client/client.py
Original file line number Diff line number Diff line change
Expand Up @@ -443,27 +443,34 @@ def get_collections(self) -> Iterator[Collection]:
call_modifier(self.modifier, collection)
yield collection

def get_items(
self, *ids: str, recursive: bool | None = None
) -> Iterator["Item_Type"]:
def get_items(self, *ids: str, recursive: bool = True) -> Iterator["Item_Type"]:
"""Return all items of this catalog.

Args:
ids: Zero or more item ids to find.
recursive: unused in pystac-client, but needed for falling back to pystac
recursive : If True, search this catalog and all children for the
item; otherwise, only search the items of this catalog. Defaults
to True.

Return:
Iterator[Item]: Iterator of items whose parent is this
catalog.
"""
if self.conforms_to(ConformanceClasses.ITEM_SEARCH):
search = self.search(ids=ids)
if recursive:
search = self.search(ids=ids)
try:
yield from search.items()
return
except APIError:
child_catalogs = [catalog for catalog, _, _ in self.walk()]
search = self.search(ids=ids, collections=[self, *child_catalogs])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it would be pretty easy to do accidentally. I think I'd prefer to just let the error raise and make it a little harder to get every single item in planetary computer for instance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern is that without something like this, many functions that call get_items simply don't work for planetary computer or similar APIs that enforce this required argument. This includes:

  • Client.get_all_items,
  • Client.walk,
  • Client.validate_all,
  • Client.describe,
  • Client.make_all_asset_hrefs_relative,
  • Client.make_all_asset_hrefs_absolute

Note that the spec doesn't say one way or another that these arguments must be optional so I'm guessing that planetary computer's API is still spec compliant technically. However, the examples show that a search without collections should be supported so I don't really know one way or the other how to interpret that:

https://github.com/radiantearth/stac-api-spec/blob/604ade6158de15b8ab068320ca41e25e2bf0e116/item-search/examples.md?plain=1#L27

Otherwise the only way to make this work for APIs like planetary computer is to override the Client class like:

import pystac_client

class Client(pystac_client.Client):
    def search(self, *args, **kwargs):
        if kwargs["collections"] is None:
            kwargs["collections"] = [self.id *[catalog.id for catalog, _, _ in self.walk()]]
        return super().search(*args, **kwargs)

pystac_client.client.Client = Client  # so that sub-catalogs also use the updated search method 

If that's the approach we want to go with that's fine, but maybe we should document this workaround in case users want to interact with planetary computer.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking the time to write that all up! I think as long as a clear error surfaces it is fine to have those methods fail on Planetary Computer. Requiring collections is not technically compliant with the spec, so I think it is better to not bake in special handling for this scenario especially since it is likely to result in a surprising user experience (setting collections to include every collection might be very very slow).

else:
search = self.search(ids=ids, collections=[self.id])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't feel quite right, since the client is a Catalog, not a Collection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right that the naming is not ideal but that's the parameter name that the API provides.

Items can be direct children of Catalogs and the API spec does not provide a separate catalogs= parameter to differentiate between catalogs and collections. Specifying the catalog id in the collections parameter works with at least one API implementation (stac-fastapi) but I guess the spec doesn't specify what to do in this edge case.

The other option is to skip the option to use the search endpoint for all non-recursive calls and do something like:

        if self.conforms_to(ConformanceClasses.ITEM_SEARCH) and recursive:
            yield from self.search(ids=ids).items()
        else:
            if not self.conforms_to(ConformanceClasses.ITEM_SEARCH):
                self._warn_about_fallback("ITEM_SEARCH")
            for item in super().get_items(
                *ids, recursive=recursive is None or recursive
            ):
                call_modifier(self.modifier, item)
                yield item

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifying the catalog id in the collections parameter works with at least one API implementation (stac-fastapi) but I guess the spec doesn't specify what to do in this edge case.

Yeah, we try to expand pystac-client with heuristics to help it work with real-world instances (rather than being strictly spec-enforcing) but this use-case is unusual enough that I'm not sure it's worth the complexity to manage.

I'm still not sure the problem we're trying to solve here is pystac-client's problem. As the original docstring said, we're not using recursive in pystac-client at all, we only use it when we fall back to pystac for non-API searches. So I'm a bit inclined to say "if pystac-client's recursion behavior isn't what you want, just use pystac directly"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the confusing thing for me as a user of pystac-client is that the recursive behaviour is inconsistent depending on whether its using the /search endpoint or not.

Currently the behaviour is:

  • if using /search: always recursive
  • otherwise: it depends on the recursive argument

If the solution is to just say don't use pystac-client in this case then let's at least document this better. Maybe change this

recursive: unused in pystac-client, but needed for falling back to pystac

to

recursive: If this client conforms to the ITEM_SEARCH conformance class, this is unused and this will always yield items recursively. Otherwise, this will only return items recursively if True.

Or something similar that talks about the distinction.

On a personal note... I don't think I'll be able to use pystac-client in my applications if we go this route.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏼 to the docs update. pystac-client is for STAC APIs, not static STAC catalogs, and our fallback to pystac is more of a convenience than a core feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok that's fine. Just so you know, the documentation talks about pystac in a way that makes it seem like pystac is more than just a convenience so you might understand why people might assume that pystac-client would align more closely with pystac than it does:

In that last link you even have the line (in the consequences heading):

"Special care should be taken to ensure that we do not break any of PySTAC’s functionality through inheritance."

Which is exactly the issue that this PR is trying to address

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I appreciate the call-out. There's been discussions over the years on whether we should even have the two libraries be separate (for one example, stac-utils/pystac#1334 (comment)). Any documentation cleanup/fixes to make things clearer for folks would be appreciated 🙇🏼.

FWIW My current thinking is that if we ever wanted to go to a v1.0 release of pystac-client, we'd want to drop inheritance altogether to avoid these problems.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, that makes sense. I understand now why pystac-client is taking this approach.

I've created a separate PR #800 that just updates the docstring as we discussed.

yield from search.items()
else:
self._warn_about_fallback("ITEM_SEARCH")
for item in super().get_items(
*ids, recursive=recursive is None or recursive
):
for item in super().get_items(*ids, recursive=recursive):
call_modifier(self.modifier, item)
yield item

Expand Down
232 changes: 232 additions & 0 deletions tests/cassettes/test_client/test_get_items_non_recursion.yaml

Large diffs are not rendered by default.

Large diffs are not rendered by default.

Large diffs are not rendered by default.

354 changes: 354 additions & 0 deletions tests/cassettes/test_client/test_recursion_on_fallback.yaml

Large diffs are not rendered by default.

43 changes: 41 additions & 2 deletions tests/test_client.py
Original file line number Diff line number Diff line change
Expand Up @@ -738,19 +738,58 @@ def test_collections_are_clients() -> None:


@pytest.mark.vcr
def test_get_items_without_ids() -> None:
def test_get_items_recursion_collections_required_without_ids() -> None:
"""
Make sure recursion using /search works when the server requires collections
when searching
"""
client = Client.open(
"https://planetarycomputer.microsoft.com/api/stac/v1/",
)
next(client.get_items())


@pytest.mark.vcr
def test_get_items_recursion_no_collections_without_ids() -> None:
"""
Make sure recursion using /search works when the server does not require collections
when searching
"""
client = Client.open(
"https://paituli.csc.fi/geoserver/ogc/stac/v1/",
)
next(client.get_items())


@pytest.mark.vcr
def test_get_items_non_recursion() -> None:
"""Make sure that non-recursive search is used when using /search"""
client = Client.open(
"https://planetarycomputer.microsoft.com/api/stac/v1/",
)
with pytest.raises(StopIteration):
next(client.get_items(recursive=False))


@pytest.mark.vcr
def test_non_recursion_on_fallback() -> None:
"""
Make sure that non-recursive search using fallback only looks for
non-recursive items
"""
path = "https://raw.githubusercontent.com/stac-utils/pystac/v1.9.0/docs/example-catalog/catalog.json"
catalog = Client.from_file(path)
with pytest.warns(FallbackToPystac), pytest.raises(StopIteration):
next(catalog.get_items(recursive=False))


@pytest.mark.vcr
def test_recursion_on_fallback() -> None:
"""Make sure that recursive search using fallback looks for recursive items"""
path = "https://raw.githubusercontent.com/stac-utils/pystac/v1.9.0/docs/example-catalog/catalog.json"
catalog = Client.from_file(path)
with pytest.warns(FallbackToPystac):
[i for i in catalog.get_items()]
next(catalog.get_items())


@pytest.mark.vcr
Expand Down
Loading