Mixin method to restrict table by keys of upstream tables #930
Conversation
|
@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 |
| return table | ||
|
|
||
|
|
||
| def check_complete_restrict(table, key): |
There was a problem hiding this comment.
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.
|
|
||
|
|
||
| # Utility Function | ||
| def safe_join(table_1, table_2): |
There was a problem hiding this comment.
I think the permissive join operator could help you here a @ b - they talk about it in the docstring here
| return restrict_from_upstream(self, key, **kwargs) | ||
|
|
||
|
|
||
| def restrict_from_upstream(table, key, max_recursion=3): |
There was a problem hiding this comment.
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
|
@CBroz1 it is my understanding that this should be closed in favor of #949 ? @samuelbray32 are you good with that? |
|
@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 |
Description
Resolves #923
restrict_from_upstreamto mixin classExample use:
spikesortingv1 pipline does several key reductions with uuid's. This operation let's you effectively search up through table layers to apply restriction.
To Do before review
merge_id->pos_merge_id)Checklist:
CITATION.cffCHANGELOG.md