in pgstac transaction extension delete operation, any item with the given id may be deleted

[philvarner]

in pgstac/transactions.py, the db is only passed the item_id, and not the collection_id the item is in. This leads me to believe that this would delete any Item with that ID, rather than being scoped to the specific collection in the path.

    async def delete_item(
        self, item_id: str, collection_id: str, **kwargs
    ) -> stac_types.Item:
        ...
        await dbfunc(pool, "delete_item", item_id) # no collection_id in call
        ...

@bitner

[drnextgis]

stac-utils/pgstac#84

[duckontheweb]

Given that PgSTAC enforces unique Item IDs within the API, this will not be an issue. If the PgSTAC behavior changes then we should revisit this.

@geospatial-jeff I believe this can be closed.

[duckontheweb]

Given that PgSTAC enforces unique Item IDs within the API, this will not be an issue. If the PgSTAC behavior changes then we should revisit this.

@geospatial-jeff I believe this can be closed.

Actually, I do not think this is true (see stac-utils/pgstac#84). Since the items tables is partitioned Items can only be unique on the combination of {partition_key} and id. Prior to PgSTAC 0.5.0 the {partition_key} was datetime, and in that version it was changed to collection. I have not tested this yet, but I think this means:

1. Multiple Items with the same id can exist (as long as they do not also have identical values for the partition key)
2. Prior to PgSTAC 0.5.0 it would be possible to add Items with duplicate ids to the same Collection as long as they have different datetime values.

@bitner Can you confirm that this is the case?

[bitner]

Yes, this is correct. We can only enforce uniqueness within a partition. In pgstac >0.5 there is always an initial partition by collection and optionally a second level partition by datetime chunks (month or year) and so it is possible to have duplicate ids that fall within different partitions.