Part.delete: forward kwargs to super.delete

[sarpit2907]

Fixes #1276

Part.delete() previously only accepted force, which prevented forwarding kwargs
supported by Table.delete() (e.g. transaction=False). This change forwards
kwargs to super().delete() when force=True while preserving the existing safety
behavior for direct part deletes.

Tests:

• pytest -q tests/test_cascading_delete.py -k forwards_kwargs

[dimitri-yatsenko]

Thanks for this fix! PR #1312 addresses this issue more comprehensively with a unified part_integrity API that replaces the previous boolean parameters.

New API in #1312

The Part.delete() method now accepts all kwargs and forwards them to Table.delete():

class Part(UserTable, metaclass=PartMeta):
    def delete(self, part_integrity: str = "enforce", **kwargs):
        """
        Args:
            part_integrity: Policy for master-part integrity. One of:
                - "enforce" (default): Error - delete from master instead.
                - "ignore": Allow direct deletion (breaks master-part integrity).
                - "cascade": Delete parts AND cascade up to delete master.
            **kwargs: Additional arguments passed to Table.delete()
                      (transaction, prompt)
        """
        if part_integrity == "enforce":
            raise DataJointError(...)
        super().delete(part_integrity=part_integrity, **kwargs)

Migration from old API

Old	New
Part.delete(force=True)	Part.delete(part_integrity="ignore")
Part.delete(force=True, transaction=False)	Part.delete(part_integrity="ignore", transaction=False)
N/A	Part.delete(part_integrity="cascade") — also deletes masters

The **kwargs forwarding now works correctly, fixing #1276.

Since #1312 includes this fix as part of a larger API improvement, we've marked it as superseding this PR. Thank you for identifying the issue!

[dimitri-yatsenko]

Hi @sarpit2907, thank you for this contribution and for addressing issue #1276!

We're closing this PR because DataJoint 2.0 introduces a more comprehensive solution for master-part delete behavior through the `part_integrity` parameter:

```python
def delete(self, part_integrity: str = "enforce", ...) -> int
```

Value	Behavior
`"enforce"`	(default) Error if parts deleted without masters
`"ignore"`	Allow deleting parts without masters
`"cascade"`	Also delete masters when parts are deleted

This provides a cleaner API than forwarding arbitrary kwargs:

```python

DataJoint 2.0 usage

Session.Trial.delete(part_integrity="ignore") # Delete parts directly
Session.Trial.delete(part_integrity="cascade") # Delete parts and their masters
```

The underlying issue (#1276) about Part table delete flexibility is fully addressed with this new parameter. We appreciate your effort in identifying this limitation!

See PR #1312 and the master-part spec for details.

[dimitri-yatsenko]

Closing in favor of DataJoint 2.0's part_integrity parameter. Thank you for your contribution!

[sarpit2907]

Thanks @dimitri-yatsenko for the review and for closing this — I understand this is tied to broader changes and may not fit the current direction.

I’ve learned a lot from the discussion and will focus next on smaller, low-risk issues (tests/docs/UX) to better align with the project roadmap.