feat(sea-orm-cli): output log about generated file name.

[kyoto7250]

PR Info

• Closes
  close : [CLI] Show progress when generating entity files #722

Adds

• Add logging during code generation for sea-orm-cli.

Breaking Changes

• No Breaking Changes

example output

❯ ../sea-orm/sea-orm-cli/target/debug/sea-orm-cli generate entity --database-url mysql://root@localhost/world --output-dir out/
Generating city.rs
    > Column `ID`: i32, auto_increment, not_null
    > Column `Name`: String, not_null
    > Column `CountryCode`: String, not_null
    > Column `District`: String, not_null
    > Column `Population`: i32, not_null
    > Column `created_at`: DateTimeUtc, not_null
Generating country.rs
    > Column `Code`: String, not_null
    > Column `Name`: String, not_null
    > Column `Continent`: Continent, not_null
    > Column `Region`: String, not_null
    > Column `SurfaceArea`: Decimal, not_null
    > Column `IndepYear`: Option<i16>
    > Column `Population`: i32, not_null
    > Column `LifeExpectancy`: Option<Decimal>
    > Column `GNP`: Option<Decimal>
    > Column `GNPOld`: Option<Decimal>
    > Column `LocalName`: String, not_null
    > Column `GovernmentForm`: String, not_null
    > Column `HeadOfState`: Option<String>
    > Column `Capital`: Option<i32>

---

It is my first PR in this repo.
Thank you in advance :)

[billy1624]

Hey @kyoto7250, thanks for the contributions! Looking good!

[kyoto7250]

@billy1624
Could I request another review?

[kyoto7250]

I missed CI failed notification.
I will check it.

The problem seems to be that tracing is not initialized during unit testing.

[kyoto7250]

I fixed it.
Could you review it again?

[billy1624]

Hey @kyoto7250, sorry for being so picky. We want to keep the code as clean as possible. I still think there is room for refactoring, please review the commit below and feel free to cherry pick it

• kyoto7250/sea-orm@issue_702...billy1624:pr/735

[kyoto7250]

@billy1624
Of course. I'll fix it.
Thank you for giving me a better way to write!

#735 (review)

[billy1624]

Thanks! @kyoto7250

[lcptrs]

Hey there, I’m still quite new to rust in general so more of question here.
When would you use std::fmt::Display trait instead? Or in other terms, why not to use it here?

[billy1624]

Hey @Irykson, welcome and good questions! I think generally speaking std::fmt::Display is for printing debug info and shows all the attribute inside a data structure. But here, we're printing column info with in custom format, hence, I don't think it's ideal to implement std::fmt::Display for this purpose.

[kyoto7250]

I aggre @billy1624 .

[lcptrs]

Thanks for the reply and your warm welcome @billy1624!
I really don't want to hijack this PR to start a discussion or a Q&A, so feel free to shut it here :)
I just found this guideline which says, Display is intended for user-facing output which was also my understanding of this trait. So I actually thought, the reasoning behind not using it here, has more to do with the fact, that get_info could be thought of a somewhat niche case and you want another default output for Display in the future.

[kyoto7250]

I just found this guideline which says, Display is intended for user-facing output which was also my understanding of this trait. So I actually thought, the reasoning behind not using it here, has more to do with the fact, that get_info could be thought of a somewhat niche case and you want another default output for Display in the future.

maybe, yes :)

and I think it is not now.

[tyt2y3]

@Irykson yeah usually what would happen is when we impl Display get_info will be called inside the function

[tyt2y3]

Thank you all for making a better developer experience for all