Mixin method to restrict table by keys of upstream tables

[samuelbray32]

Description

Resolves #923

• add method restrict_from_upstream to mixin class
• prevents need for user to know all joins necessary to link a key to a deep table entry

Example use:
spikesortingv1 pipline does several key reductions with uuid's. This operation let's you effectively search up through table layers to apply restriction.

from spyglass.spikesorting.spikesorting_merge import SpikeSortingOutput
table = sgs.CurationV1()
key = {"nwb_file_name":"BS2820231107_.nwb","sort_group_id":28}
result = table.restrict_from_upstream(key,max_recursion=5)
result

To Do before review

• Address case of aliasing between parent and child table (e.g. merge_id -> pos_merge_id)
• Make better stopping condition by tracking previously found restriction items up through recursion
• Remove development print statements
• Add examples in tutorial notebooks

Checklist:

• This PR should be accompanied by a release: (yes/no/unsure)
• (If release) I have updated the CITATION.cff
• I have updated the CHANGELOG.md
• I have added/edited docs/notebooks to reflect the changes

[samuelbray32]

@CBroz1 whenever you have time could you look at this and give thoughts on how to track aliasing between tables? Or point me to where you solved it before in delete cases. No rush and thanks!

[CBroz1]

Just a couple first pass comments. I can try running to play around with it later this week

[CBroz1]

dj has a builtin for this called 'assert_join_compatibility' - if adopted, it would need to be wrapped in a try/except and call it using the key as a QueryExpression, but I'm inclined to let them handle this kind of thing rather than add more for us to maintain.

[CBroz1]

I think the permissive join operator could help you here a @ b - they talk about it in the docstring here

[CBroz1]

I'm thinking I could fold this into either dj_chains or dj_graph to make use of how restr are cascaded there. it might cutdown on the footprint for this feature

[edeno]

@CBroz1 it is my understanding that this should be closed in favor of #949 ? @samuelbray32 are you good with that?

[samuelbray32]

@edeno, agreed. I think that one is more robust. Let's not delete the branch for a little as we merge in and test though