You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Use alias_generator=to_camel on Pydantic models instead of manual per-field aliases #1954
We're on Pydantic ≥2.11. Many models map snake_case Python fields to camelCase external keys (storage/state/API JSON), and today every field spells its alias out by hand. For example in src/crawlee/statistics/_models.py:
Fields then drop the manual alias (stats_id: int | None = None) and still (de)serialize as statsId. We already standardize on validate_by_name=True, validate_by_alias=True (the 2.11 successors of populate_by_name), so the only new piece is alias_generator. Best placed on a shared base model, since subclasses currently redeclare the config.
Where it makes sense
Apply to models that already use camelCase aliases: Request, SessionModel, StatisticsState, the storage_clients/models.py set, event data classes, etc.
Keep an explicit Field(alias=...) wherever to_camel produces the wrong key (acronyms / irregular casing). Each field's generated alias must equal the current one.
Skip models whose serialized form is snake_case, e.g. RequestQueueState in _file_system/_request_queue_client.py, and Configuration (BaseSettings with env-var AliasChoices).
Scope
Refactor only. The wire format must not change; generated aliases have to match the existing ones, guarded by the current (de)serialization tests.
Activity
refactor: derive camelCase model aliases with an alias generator (#2319)
vdusek commentedon Oct 13, 2026
resolved by #2319
refactor: derive camelCase model aliases with an alias generator (#2319)