Use input ident instead of associated type projections in ActiveModel derive

[svix-jplatte]

Overview

Currently, sea-orm's ActiveModel derive generates impls like impl From<<Entity as sea_orm::EntityTrait>::Model> for ActiveModel. This prevents any other From<LocalType> for ActiveModel impls from being added from other crates that depend on the crate that defines the ActiveModel. This is a bug in rustc: rust-lang/rust#85898

This 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

• Simplify ActiveModel derive output to work around a compiler bug

[svix-jplatte]

Gentle ping @tyt2y3

[tyt2y3]

GitHub seems to have skipped the button to let us run CI

[tyt2y3]

Now it's running

[tyt2y3]

I found that the associated type projection was introduced in 890464f

thank you for digging this up. I have nearly forgotten the context. I think the original motivation is to use DeriveActiveModel outside of the normal entity definition, in which we'd have multiple ActiveModel sharing the same Model. But that use case has been replaced by DeriveIntoActiveModel soon after.

[tyt2y3]

This prevents any other From for ActiveModel impls from being added from other crates that depend on the crate that defines the ActiveModel

@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.

[svix-jplatte]

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, tests/? They would be different from the other tests in that they're not actually test binaries, but individual cargo packages with their own Cargo.tomls.

[tyt2y3]

Can you put the entity in https://github.com/SeaQL/sea-orm/tree/master/src/tests_cfg and then use it in integration tests?
I think the crate boundary would work here?

[svix-jplatte]

I didn't know about that module, in that case I don't even need to define a new entity, an existing one using DeriveActiveModel works just fine. Pushed a test now, and verified that it fails to compile on master.

[svix-jplatte]

Ping @tyt2y3 looks like CI has succeeded :)

[github-actions]

🎉 Released In 1.1.1 🎉

Thank you everyone for the contribution!
This feature is now available in the latest release. Now is a good time to upgrade!
Your participation is what makes us unique; your adoption is what drives us forward.
You can support SeaQL 🌊 by starring our repos, sharing our libraries and becoming a sponsor ⭐.