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

Use checked signatures for Table and Column #12283

Merged
merged 33 commits into from
Feb 19, 2025

Conversation

radeusgd
Copy link
Member

@radeusgd radeusgd commented Feb 14, 2025

Pull Request Description

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.
  • If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
    or the Snowflake database integration, a run of the Extra Tests has been scheduled.
    • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

@radeusgd radeusgd added the CI: No changelog needed Do not require a changelog entry for this PR. label Feb 14, 2025
@radeusgd radeusgd self-assigned this Feb 14, 2025
@radeusgd radeusgd force-pushed the wip/radeusgd/check-table-column-methods branch from b0a2843 to f295430 Compare February 14, 2025 08:19
@Akirathan Akirathan mentioned this pull request Feb 14, 2025
5 tasks
@radeusgd radeusgd force-pushed the wip/radeusgd/check-table-column-methods branch 2 times, most recently from da8626b to d661aab Compare February 17, 2025 12:42
…le that anyway reporting as Invalid_Value_Type
@radeusgd radeusgd force-pushed the wip/radeusgd/check-table-column-methods branch from d661aab to 9cfd48f Compare February 17, 2025 18:26
@radeusgd radeusgd marked this pull request as ready for review February 17, 2025 19:31
@@ -1864,8 +1793,7 @@ type DB_Column
import Standard.Examples

example_contains = Examples.text_column_1.is_in [1, 2, 5]
is_in : DB_Column | Vector -> DB_Column
is_in self vector =
is_in self (vector : DB_Column | Vector | Array) -> DB_Column =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we consider Array a user-facing type? I rarely see it used anywhere but tests and benchmarks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, I guess not necessarily.

But it is here needed to make expressions work (before the type was unchecked so the Array went through). It is the de-facto used type signature.

However, I'm happy to create a ticket to remove | Array from here and fix the related expression syntax issue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's important right now, I was just wondering what the status of Array is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is hardly used in public user-facing APIs, so I think it may be worth to move toward removing it from this API as that usage is mostly internal.

@@ -199,8 +195,7 @@ type DB_Table
Arguments:
- index: The index of the row to get within the table.
- if_missing: The value to use if the selector isn't present.
get_row : Integer -> Any -> Any
get_row self index:Integer=0 ~if_missing=Nothing =
get_row self index:Integer=0 ~if_missing:Any=Nothing -> Any =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
get_row self index:Integer=0 ~if_missing:Any=Nothing -> Any =
get_row self index:Integer=0 ~if_missing:Any=Nothing -> Row ! Index_Out_Of_Bounds =

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize that this PR isn't for completely fixing all signatures, I'm just pointing out a few obvious existing problems.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No but thanks for pointing them out, probably worth fixing them up if we can.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just double checked and the correct signature is

Suggested change
get_row self index:Integer=0 ~if_missing:Any=Nothing -> Any =
get_row self index:Integer=0 ~if_missing:Any=Nothing -> Row|Any =

We are not throwing Index_Out_Of_Bounds here but returning if_missing. Because if_missing can be Any, then the type must be Row | Any because we don't know the type of if_missing.

If we had polymorphic types the type could be more precise by making:

Suggested change
get_row self index:Integer=0 ~if_missing:Any=Nothing -> Any =
get_row self index:Integer=0 ~if_missing:'a=Nothing -> Row | 'a =

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This calls last_row which can throw Index_Out_Of_Bounds -- do we not include transitive throws here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Oh so you've found a bug 😅 I'd probably get it fixed in separate PR to keep this PR mostly pure refactor only.
  2. To be honest I'm not sure if we have consistent guidelines on it. In many cases the list of possible errors is not exhaustive. We probably should revisit that but I guess we may want to keep it to only most common errors for now, as listing all may sometimes be huge. Also there's no checking of that currently.

Re (1) - the bug is - get_row should return if_missing (Nothing by default) if called with -1 on an empty table, but you are right that it is actually raising an error. That is an implementation bug, because we do the -1 check before the bounds check. We should rearrange the code to do bounds check first and return if_missing if out-of-bounds, then the last_row call would be guaranteed to not fail.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to have almost no tests for get_row at present.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reported as #12317

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these return exceptions aren't checked at all then we shouldn't worry about it too much now; if we implement that checking, that will find all of our omissions 😄

@radeusgd radeusgd added the CI: Ready to merge This PR is eligible for automatic merge label Feb 19, 2025
@mergify mergify bot merged commit 59c82f3 into develop Feb 19, 2025
45 of 48 checks passed
@mergify mergify bot deleted the wip/radeusgd/check-table-column-methods branch February 19, 2025 12:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update Table/Column operations' signatures to be checked
2 participants