Proc macro parsing with darling and test

[Diwakar-Gupta]

Still Working need feedback

PR Info

Fixes
Problem discussed at #394 (comment).

Related PR

#1560

Tasks

• Replace manually parsing with darling
• Write test for parser

File Changed

1. sea-orm-macros/Cargo.toml added darling dependency
2. sea-orm-macros/src/derives/model.rs modified parser and added test

[billy1624]

Hey @Diwakar-Gupta, thanks for the work!!

1. the test needs to be done in a different way

I think the test is on the right track! :)

2. we need to change structure struct DeriveModel

Yes, would be better if we replace DeriveModel with DeriveModelDarling. As DeriveModelDarling already have all the info of DeriveModel.

Btw... a small nitpick. Should we name the derive data struct without the Daring prefix? For example, naming DeriveModelDarling as DeriveModel.

3. Code generation need's to be changed

I'm not sure what you mean here. Could you please clarify?

4. if this is going in right direction or not.

Good POC! Was in the right direction!
Appreciated the help :)

[Diwakar-Gupta]

Thanks for the feedback.

I will look after replacing DeriveModel with DeriveModelDarling. This will lead to changes in impl_from_query_result impl_model_trait as they both depend on struct DeriveModel.

[tyt2y3]

Wow, interesting. I have never used darling. Seems like it can make the code much cleaner!

[billy1624]

Yep, wanna get rid of the parsing mess ASAP loll

[billy1624]

Hey @Diwakar-Gupta, I think you leave a comment here yesterday night but it's now gone. Anything I could help?

[Diwakar-Gupta]

darling cant parse column_ident because it has out own logic so made it Option and then calculated it in constructor. Not sure if having a function get_column_ident will be better.
Having function will remove most of the calculation code in constructor but then we wont be able to use column_ident variable and have to call function( it has to be called twice ).

[Diwakar-Gupta]

@billy1624
The comment was a report of changes done; Then I did some more changes and it became irrelevant.
Here is the latest summary.

All this are also commented in code.

1. Previously DeriveModel had processed data, removing it has introduced some extra processing in impl_from_query_result and impl_model_trait functions. But it is manageable at least in my opinion.

2. struct is only supported this is ensured by darling now, and default darling error message is shown to user for now. cant give custom error message unless darling makes some necessary module public.

[billy1624]

Hey @Diwakar-Gupta, I saw your implementation then I decided to try it before leaving comments. My experiment result: #1560

Feel free to copy the useful bits to your PR. Hopefully we can combine the "good" into single PR.

[Diwakar-Gupta]

Thanks @billy1624 I will study the reference you have given.

[Diwakar-Gupta]

hey @billy1624 i have used your pr #1560 and fixed the merge conflict.