Fix --allow-population-by-field-name for pydantic v2 dataclass output#3013
Conversation
…koxudaxi#3010) DataClass.__init__ never read allow_population_by_field_name from extra_template_data, so the flag was silently ignored for pydantic_v2.dataclass output. Add _CONFIG_ATTRIBUTES processing (matching the BaseModel pattern) to emit populate_by_name in ConfigDict, with validate_by_name support for --target-pydantic-version 2.11. Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds version-aware mapping of dataclass ConfigDict attributes for Pydantic v2 generation and updates tests/expected outputs to validate populate/validate-by-name behavior across v2 versions. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Merging this PR will not alter performance
|
There was a problem hiding this comment.
🧹 Nitpick comments (3)
src/datamodel_code_generator/model/pydantic_v2/dataclass.py (2)
120-127: Consider centralizing version-based config selection to avoid drift.This method duplicates the selector in
src/datamodel_code_generator/model/pydantic_v2/base_model.py(same version branching). A shared helper/mixin would reduce future divergence risk.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/datamodel_code_generator/model/pydantic_v2/dataclass.py` around lines 120 - 127, The _get_config_attributes method duplicates version-branching logic present in base_model.py; extract the version selector into a single shared helper (e.g., a function or mixin) that accepts the extra_template_data (or target_version) and returns the appropriate config constant, then replace the branching in dataclass._get_config_attributes and the analogous method in base_model to call that shared helper; reference the symbols TargetPydanticVersion, _CONFIG_ATTRIBUTES_V2_11, _CONFIG_ATTRIBUTES_V2, and _get_config_attributes when locating places to replace.
38-48: Make key precedence explicit for duplicate destination mappings.Both
allow_population_by_field_nameandpopulate_by_nametarget the same config key. Today precedence is implicit via list order. Consider documenting the intended winner (or enforcing it in code) to avoid accidental behavior changes during future reordering.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/datamodel_code_generator/model/pydantic_v2/dataclass.py` around lines 38 - 48, The lists _CONFIG_ATTRIBUTES_V2 and _CONFIG_ATTRIBUTES_V2_11 contain duplicate destination mappings for allow_population_by_field_name and populate_by_name which makes precedence implicit; update the dataclass mapping so the intended winner is explicit—either remove the duplicate entry for the losing key from those lists, add an explicit priority flag to the ConfigAttribute type and set it for allow_population_by_field_name vs populate_by_name, or update the resolution logic that consumes these lists to prefer a named winner—ensure you modify ConfigAttribute and the consumer code together (references: _CONFIG_ATTRIBUTES_V2, _CONFIG_ATTRIBUTES_V2_11, ConfigAttribute, keys allow_population_by_field_name and populate_by_name) and add a short comment documenting the chosen precedence.tests/main/jsonschema/test_main_jsonschema.py (1)
1847-1861: Add coverage for the--target-pydantic-version 2.11path.This test covers the default v2 dataclass path well, but the PR also introduces version-specific config mapping. Please add a companion test with
target_pydantic_version="2.11"so the new branch is regression-protected.Proposed test addition
+def test_main_generate_pydantic_v2_dataclass_allow_population_by_field_name_target_2_11(tmp_path: Path) -> None: + """Test pydantic_v2.dataclass with allow_population_by_field_name for target pydantic 2.11.""" + output_file: Path = tmp_path / "output.py" + input_ = (JSON_SCHEMA_DATA_PATH / "simple_string.json").relative_to(Path.cwd()) + assert not input_.is_absolute() + generate( + input_=input_, + input_file_type=InputFileType.JsonSchema, + output=output_file, + output_model_type=DataModelType.PydanticV2Dataclass, + allow_population_by_field_name=True, + target_pydantic_version="2.11", + ) + + assert_file_content(output_file, "pydantic_v2_dataclass_populate_by_name_target_2_11.py")🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/main/jsonschema/test_main_jsonschema.py` around lines 1847 - 1861, Add a new test mirroring test_main_generate_pydantic_v2_dataclass_allow_population_by_field_name named something like test_main_generate_pydantic_v2_dataclass_allow_population_by_field_name_target_2_11 that calls generate with the same parameters but adds target_pydantic_version="2.11" (keep input_ and output_file setup identical) and asserts the generated output matches the expected fixture (use a new fixture file name such as pydantic_v2_dataclass_populate_by_name_p2_11.py or reuse appropriate expected content). This will exercise the version-specific config mapping path in generate and protect the 2.11 branch.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/datamodel_code_generator/model/pydantic_v2/dataclass.py`:
- Around line 120-127: The _get_config_attributes method duplicates
version-branching logic present in base_model.py; extract the version selector
into a single shared helper (e.g., a function or mixin) that accepts the
extra_template_data (or target_version) and returns the appropriate config
constant, then replace the branching in dataclass._get_config_attributes and the
analogous method in base_model to call that shared helper; reference the symbols
TargetPydanticVersion, _CONFIG_ATTRIBUTES_V2_11, _CONFIG_ATTRIBUTES_V2, and
_get_config_attributes when locating places to replace.
- Around line 38-48: The lists _CONFIG_ATTRIBUTES_V2 and
_CONFIG_ATTRIBUTES_V2_11 contain duplicate destination mappings for
allow_population_by_field_name and populate_by_name which makes precedence
implicit; update the dataclass mapping so the intended winner is explicit—either
remove the duplicate entry for the losing key from those lists, add an explicit
priority flag to the ConfigAttribute type and set it for
allow_population_by_field_name vs populate_by_name, or update the resolution
logic that consumes these lists to prefer a named winner—ensure you modify
ConfigAttribute and the consumer code together (references:
_CONFIG_ATTRIBUTES_V2, _CONFIG_ATTRIBUTES_V2_11, ConfigAttribute, keys
allow_population_by_field_name and populate_by_name) and add a short comment
documenting the chosen precedence.
In `@tests/main/jsonschema/test_main_jsonschema.py`:
- Around line 1847-1861: Add a new test mirroring
test_main_generate_pydantic_v2_dataclass_allow_population_by_field_name named
something like
test_main_generate_pydantic_v2_dataclass_allow_population_by_field_name_target_2_11
that calls generate with the same parameters but adds
target_pydantic_version="2.11" (keep input_ and output_file setup identical) and
asserts the generated output matches the expected fixture (use a new fixture
file name such as pydantic_v2_dataclass_populate_by_name_p2_11.py or reuse
appropriate expected content). This will exercise the version-specific config
mapping path in generate and protect the 2.11 branch.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/datamodel_code_generator/model/pydantic_v2/dataclass.pytests/data/expected/main/jsonschema/pydantic_v2_dataclass_populate_by_name.pytests/main/jsonschema/test_main_jsonschema.py
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3013 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 94 94
Lines 18130 18152 +22
Branches 2099 2101 +2
=========================================
+ Hits 18130 18152 +22
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Co-Authored-By: Claude Opus 4.6 <[email protected]>
Breaking Change AnalysisResult: No breaking changes detected Reasoning: This PR is a bug fix, not a breaking change. The --allow-population-by-field-name flag was documented to add populate_by_name configuration to generated output, but it was silently ignored for pydantic_v2.dataclass output. This PR fixes that bug so the flag now works as documented and intended. Users who passed this flag expected the behavior that is now correctly implemented. No defaults changed, no API changed, no templates need updating - the flag simply now works correctly instead of being silently ignored. This analysis was performed by Claude Code Action |
|
🎉 Released in 0.54.1 This PR is now available in the latest release. See the release notes for details. |
Fixes #3010
--allow-population-by-field-namewas silently ignored when using--output-model-type pydantic_v2.dataclass.DataClass.__init__never read the flag fromextra_template_data, sopopulate_by_namewas never passed to ConfigDict.Added
_CONFIG_ATTRIBUTESprocessing (matching the BaseModel pattern), with validate_by_name support for --target-pydantic-version 2.11.Before:
After:
Summary by CodeRabbit
Bug Fixes
New Features
Tests