SeaQL/sea-orm

Refactor macro implmentions

Open

#3,119 opened on Jul 7, 2026

View on GitHubContributor guide
 (2 comments) (0 reactions) (0 assignees)Rust (718 forks)auto 404
good first issuehelp-wanted

Repository metrics

Stars
 (9,827 stars)
PR merge metrics
 (PR metrics pending)

Description

I did some refactoring in #3118, but the current macro implementation is still quite messy.

The refactoring mainly split the code that mixed parsing and expansion into separate steps.

Ideally, we should remove bae. We could consider using darling instead, or just write the parsing code manually. The current macro parser supports all possible combinations, and I worked around that by adding an extra normalization step, but it would be better to clean up the related code.

There are also many other things that can be simplified. I noticed a lot of recurring patterns like duplicated logic across branches, using parse(&str) instead of syn::parse_quote, using manually constructed strings and Idents instead of format_ident, and converting types such as Type or Ident into String for comparison and then converting them back, rather than comparing them directly.

I also noticed that some state can be derived rather than stored.

For contributors who want to help with this, I would suggest starting with small, focused changes, ideally by addressing one category of issues at a time. Furthermore, please don't open LLM-generated PRs.

Contributor guide

Research direction
Start by familiarizing yourself with the existing macro code in the repository. Select one of the improvement categories mentioned (e.g., replacing parse(&str) with syn::parse quote, using format ident instead of manual string construction, etc.). Search for all instances of that pattern in the macro source files. Make small, focused changes to address that category. Ensure you understand the impact on parsing and expansion. Avoid large scale changes or LLM generated code.
Tech stack
rust
Domain
backenddatabase
Issue type
Refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
Rust
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
55