googleapis / python-firestore

Apache License 2.0
214 stars 73 forks source link

list_indexes function returns all indexes in the database, not within a collection #874

Open fbjorn opened 6 months ago

fbjorn commented 6 months ago

Hi,

I'm trying to list composite indexes within a specific collection. Documentation for ListIndexesRequest says:

 parent (str):
            Required. A parent name of the form
            ``projects/{project_id}/databases/{database_id}/collectionGroups/{collection_id}``

And since parent expects a collection id at the end, I assume it should return indexes only within this collection, however it's listing ALL indexes of my database.

I just don't understand if it's an expected behavior, or a bug. If you have a suggestion how I can achieve it, I would appreciate some help.

Environment details

Code example

from google.cloud.firestore_admin_v1.services.firestore_admin import FirestoreAdminAsyncClient
from google.cloud.firestore_admin_v1 import ListIndexesRequest

async def get_existing_indexes(
    client: FirestoreAdminAsyncClient, path: str
):
    raw_indexes = []
    request = ListIndexesRequest({"parent": f"{path}"})
    operation = await client.list_indexes(request=request)
    async for page in operation.pages:
        raw_indexes.extend(list(page.indexes))
    print([index.name for index in raw_indexes])
    return raw_indexes

If I run this function with path="projects/<>/databases/(default)/collectionGroups/fooBar", I'll get these (project name obfuscated):

    "projects/<>/databases/(default)/collectionGroups/fooBar/indexes/CICAgLjRyYIK",
    "projects/<>/databases/(default)/collectionGroups/fooBar/indexes/CICAgJil0IYK",
    "projects/<>/databases/(default)/collectionGroups/anotherCollection/indexes/CICAgLiI64sK",
    "projects/<>/databases/(default)/collectionGroups/anotherCollection/indexes/CICAgNirtJAK",

As you can see, indexes from another collection are still in the response.

Thanks!

daniel-sanche commented 2 months ago

My expectation for that function match yours, so this seems like a possible bug to me.

This part of the codebase is fully auto-generated, however, so the bug wouldn't be with in this client library. I opened an issue with the backend team to get more information