Skip to content
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

Add more table api Value structuring #831

Open
devinrsmith opened this issue Jul 8, 2021 · 1 comment
Open

Add more table api Value structuring #831

devinrsmith opened this issue Jul 8, 2021 · 1 comment
Assignees
Labels
core Core development tasks table api
Milestone

Comments

@devinrsmith
Copy link
Member

io.deephaven.api.value.Value could use more structuring. Potential inspiration from table.proto.

@devinrsmith devinrsmith added table api core Core development tasks labels Jul 8, 2021
@devinrsmith devinrsmith added this to the July 2021 milestone Jul 8, 2021
@devinrsmith devinrsmith self-assigned this Jul 8, 2021
@devinrsmith
Copy link
Member Author

Useful for io.deephaven.api.Selectable and io.deephaven.api.filter.FilterCondition.

Allows the user to programmatically structure something like:

table.where("Foo==(byte)3")
table.view("X=(short)42")

etc.

@devinrsmith devinrsmith modified the milestones: July 2021, Backlog Aug 9, 2021
devinrsmith added a commit that referenced this issue May 4, 2023
The interfaces of `io.deephaven.api.expression.Filter`, `io.deephaven.api.expression.Expression`, and `io.deephaven.api.value.Value` were originally developed and influenced based on the structure of the gRPC messages and engine capabilities; and they were explicitly called out due to lack of completeness with respect to these constructions in #829, #830, and #831.

Upon delving into SQL work in #3473, it became clear that it was time to update these interfaces with the more expressive structures that could better preserve the semantics and intentions of the SQL expressions. The alternative involves throwing up our hands and using `io.deephaven.api.RawString` everywhere instead.

For example, it was possible before to represent the filters of `Foo > Bar` and `Foo > 42`, but it was not possible to represent `Foo > Bar + 42` (again, without dropping down into RawString); and equivalently, an Expression could be `Bar`, or `42`, but not `Bar + 42` (essentially, limiting what could be represented in the case of view or update Selectable).

This PR greatly expands the expressiveness of these interfaces while also cleaning up the hierarchy. The main highlights:

    * `Filter` is now an `Expression`
    * `FilterCondition` renamed `FilterComparison`
    * `Value` is gone; in its place, a more specific `Literal` structure
    * Usages of `Value` replaced with the more generic `Expression` type (for example, LHS / RHS of `FilterComparison` are now Expressions instead of Values)
    * `Function` / `Method` created to represent function / method calls without needing to drop into `RawString` (for example, we might want to have `io.deephaven.sql.Functions#sum_sql` as something that can be properly referenced).
    * Moved `QueryConstants` to new project `query-constants`
    * Added filter README
    * Added `FilterPattern` / `FilterIn` filters
    * Expanded `Literal` to all primitives
    * Renamed `PatternFiltern` and made package private

This PR does not aim to update the gRPC layer at this time, mainly do to time considerations and that #3473 is limited to execution completely within the server environment. That said, we would likely benefit from updating the gRPC layer to be more expressive in the ways proposed here.

There's also potential in the future for the engine layer to benefit from the additional structuring here; potentially constructing more advanced filters and expressions without needing to compile strings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core development tasks table api
Projects
None yet
Development

No branches or pull requests

1 participant