-
Notifications
You must be signed in to change notification settings - Fork 3
Add KeySet.union operation #123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Introduces a new `KeySet.union` operation which combines two KeySets with the same schema into a single KeySet containing all keys contained in either KeySet. For the purposes of op-tree rewriting, this operation is relatively opaque; most other operations can't be pulled through it safely, so the only way unions are rewritten is to reorder operands and restructure nested unions. In principle filters and subtraction could be pushed down through it, but it seems unlikely to me that anyone will care if we can detect that `ks1.union(ks2).filter(cond)` is equivalent to `ks1.filter(cond).union(ks2.filter(cond))`. `tmlt.analytics.keyset._keyset` was also rewritten to use the pipe syntax for unions instead of `typing.Union`, as the name conflict was confusing.
| + textwrap.indent(str(self.right), " ") | ||
| ) | ||
|
|
||
| def decompose( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Open question for another MR: do we need this decomposition logic anymore? I don't think anything that used it was open-sourced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That matches my recollection; I think we can probably get rid of it.
| + textwrap.indent(str(self.right), " ") | ||
| ) | ||
|
|
||
| def decompose( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That matches my recollection; I think we can probably get rid of it.
| # TODO(tumult-labs/tumult#3384): Mention the behavior of this method in | ||
| # terms of its interation with KeySetPlans in the docstring and to | ||
| # the below error message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this mean exactly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this was a copy from the other methods on the class -- we should recreate the relevant issue and point this at it, but it's a reminder to update the documentation/exception text for these methods when KeySet.detect becomes usable.
Introduces a new
KeySet.unionoperation which combines two KeySets with matching schemas into a single KeySet containing all keys contained in either KeySet.For the purposes of op-tree rewriting, this operation is relatively opaque; most other operations can't be pulled through it safely, so the only way unions are rewritten is to reorder operands and restructure nested unions. In principle filters and subtraction could be pushed down through it, but it seems unlikely to me that anyone will care if we can detect that
ks1.union(ks2).filter(cond)is equivalent toks1.filter(cond).union(ks2.filter(cond)).tmlt.analytics.keyset._keysetwas also rewritten to use the pipe syntax for unions instead oftyping.Union, as the name conflict was confusing.#122