-
-
Notifications
You must be signed in to change notification settings - Fork 518
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 input ident instead of associated type projections in ActiveModel derive #2349
Conversation
Gentle ping @tyt2y3 |
GitHub seems to have skipped the button to let us run CI |
Now it's running |
thank you for digging this up. I have nearly forgotten the context. I think the original motivation is to use |
@svix-jplatte can you also include a test case for this? I want to understand what did not compile for you, and be sure that we'd not break it in the future. |
This issue only manifests with multiple crates involved. Should I create two dummy crates that are just a regular part of the workspace and compiled as part of it? Where would I put them, |
Can you put the entity in https://github.com/SeaQL/sea-orm/tree/master/src/tests_cfg and then use it in integration tests? |
6667f60
to
095c494
Compare
I didn't know about that module, in that case I don't even need to define a new entity, an existing one using |
Ping @tyt2y3 looks like CI has succeeded :) |
🎉 Released In 1.1.1 🎉Thank you everyone for the contribution! |
Overview
Currently, sea-orm's
ActiveModel
derive generates impls likeimpl From<<Entity as sea_orm::EntityTrait>::Model> for ActiveModel
. This prevents any otherFrom<LocalType> for ActiveModel
impls from being added from other crates that depend on the crate that defines theActiveModel
. This is a bug in rustc: rust-lang/rust#85898This PR works around that by not using associated type projections for these impls. I couldn't figure out why this was done in the first place, as it seems like the real type this would resolve to would always be the input type of the derive macro. Maybe I'm wrong about that.
I found that the associated type projection was introduced in 890464f, and an example was updated but at the same time but I fail to see how it would be impacted by this change. Maybe CI will tell.
Changes
ActiveModel
derive output to work around a compiler bug