8000 Fix non_exhaustive enums missing arms by Huliiiiii · Pull Request #2607 · SeaQL/sea-orm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix non_exhaustive enums missing arms #2607

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

Merged
merged 21 commits into from
Jun 9, 2025
Merged

Conversation

Huliiiiii
Copy link
@Huliiiiii Huliiiiii commented May 25, 2025

PR Info

  • Closes
  • Dependents:

New Features

Bug Fixes

Breaking Changes

  • Removed ExprTrait re-export from sea_orm::entity::prelude due to potential conflicts with PartialEq and PartialOrd methods.

Changes

Copy link
Member
@Expurple Expurple left a comment

Choose a reason for hiding this comment

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

Thank you.

cargo test --workspace doesn't pass, need to add more arms.

Copy link
Member
@Expurple Expurple left a comment

Choose a reason for hiding this comment

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

Thank you. cargo test --workspace passes. We've discovered all relevant match statements*. Now we need to decide what to do with them. See the other comments

*At least, under this default test configuration. @tyt2y3, can you trigger a CI run, please? It could find more

@tyt2y3
Copy link
Member
tyt2y3 commented Jun 8, 2025

It now contains changes needed for SeaQL/sea-query#890 as well

@tyt2y3 tyt2y3 marked this pull request as ready for review June 8, 2025 22:39
@Expurple
Copy link
Member
Expurple commented Jun 9, 2025

@tyt2y3, we already had #2606 for that. Btw, it's ready to be merged.

Here, everything looks OK too, but we need to fix the remaining ExprTrait-related CI failures to know for sure

@Expurple Expurple mentioned this pull request Jun 9, 2025
4 tasks
@tyt2y3
Copy link
Member
tyt2y3 commented Jun 9, 2025

Everything is now okay. Those examples are expected to fail

@Expurple
Copy link
Member
Expurple commented Jun 9, 2025

Those examples are expected to fail

Why? What's the deal here? I'm out of the loop

@tyt2y3
Copy link
Member
tyt2y3 commented Jun 9, 2025

Those examples are expected to fail

Why? What's the deal here? I'm out of the loop

those examples depends on downstream crates: loco and seaography. we have our own fork of loco for now, so may be we can use git dependency there, then everything should work

@Expurple
Copy link
Member
Expurple commented Jun 9, 2025

Yeah, I think we should use git dependencies for now. And when CI fails, we fix the fork to make CI pass. This will also help to assess the breakage and prevent the merge if it's too bad. No different from fixing SeaORM before merging breaking SeaQuery PRs

@tyt2y3
Copy link
Member
tyt2y3 commented Jun 9, 2025

Actually, I have a counter example to consider:

use crate::ExprTrait;

struct MyType(String);

impl PartialEq for MyType {
    fn eq(&self, other: &Self) -> bool {
        self.0.eq(&other.0)
    }
}

it collided with std::cmp::PartialEq::eq

self.0.eq(&other.0)
   |         ^^^^^^^^^^^^^^^^^^^ expected `bool`, found `SimpleExpr`

is this annoyance acceptable?

this is the only change required in seaography

@Expurple
Copy link
Member
Expurple commented Jun 9, 2025

ExprTrait has always had PartialOrd-named methods that could cause these issues. I even documented this right from the start. Search for this in SeaQuery:

// Sometimes, you'll have to qualify the call because of conflicting std traits.

ExprTrait adopted these methods from Expr and SimpleExpr, where these inherent methods shadowed the PartialOrd methods instead of resulting in a conflict error.

In my experience, these conflicts are very rare. In my queries, I usually compare a column and a value, an expression and a value, a column and an expression, etc. These pairs of different types don't have PartialOrd implementations. You won't compare a String to a String in a real query 😁 And when I mean to call PartialEq::eq, I always use ==. It's more readable, and now it's nice to know that it also helps to avoid conflicts. My 50k LoC codebase has one qualified ExprTrait:: call, but I's the equals method and done because of rustfmt, not because of conflicts. So, not a single conflict in my codebase so far. And I've already refactored it aggressively to use ExprTrait and avoid verbose Expr wrappers.

After SeaQL/sea-query#890, the only difference is that now you need to use ExprTrait in files that didn't use it, but used inherent Expr and SimpleExpr methods. I've updated the "migration guide" in that PR to mention the potential conflicts.

If this conflict really bothers you, we could use this major release to rename these methods into something more verbose that doesn't conflict. But IMO, this breaking change and verbosity is not worth it. These conflicts are rare

@tyt2y3
Copy link
Member
tyt2y3 commented Jun 9, 2025

If this conflict really bothers you

I think it's acceptable. but then I can't put it in prelude.

I will merge this now and fix other examples, easier to have it on master

@Expurple
Copy link
Member
Expurple commented Jun 9, 2025

Ok, I'll mention the prelude in the PR description

@tyt2y3 tyt2y3 merged commit 9cdb530 into SeaQL:master Jun 9, 2025
31 of 36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0