Caching of models for dataclass sub types apparently ignores Config.alias_generator

[0rd0g]

Initial Checks

• I have searched GitHub for a duplicate issue and I'm sure this is something new
• I have searched Google & StackOverflow for a solution and couldn't find anything
• I have read and followed the docs and still think this is a bug
• I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)

Description

With classes derived from BaseModel which contain dataclass types as members, the schemas for those dataclasses depend on the order in which the BaseModel classes are declared. Normally this is not an issue, but if you have a BaseModel class whose Config uses a custom alias_generator, this becomes an issue.


The first-declared BaseModel class will dictate the cached schema of the contained dataclass types.

Example Code

from dataclasses import dataclass
from inflection import camelize
from pydantic import BaseModel, Extra


@dataclass
class Foo:
    first_foo: str
    second_foo: int


class CamelBaseModel(BaseModel):
    class Config:
        alias_generator = camelize
        allow_population_by_field_name = True
        extra = Extra.allow


bar_first = False

if bar_first:
    class Bar(BaseModel):
        first_bar: Foo


    class Baz(CamelBaseModel):
        first_baz: Foo


    BarSchema = Bar.schema()  # OK
    BazSchema = Baz.schema()  # WRONG - Fields of Foo not camel-cased
else:
    class Baz(CamelBaseModel):
        first_baz: Foo


    class Bar(BaseModel):
        first_bar: Foo

    BarSchema = Bar.schema()  # WRONG - Fields of Foo now camel-cased
    BazSchema = Baz.schema()  # OK

Python, Pydantic & OS Version

pydantic version: 1.10.2
            pydantic compiled: True
                 install path: /Users/Nick/miniforge3/lib/python3.9/site-packages/pydantic
               python version: 3.9.1 | packaged by conda-forge | (default, Dec  9 2020, 01:07:47)  [Clang 11.0.0 ]
                     platform: macOS-12.4-arm64-arm-64bit
     optional deps. installed: ['typing-extensions']

Affected Components

• Compatibility between releases
• Data validation/parsing
• Data serialization - .dict() and .json()
• JSON Schema
• Dataclasses
• Model Config
• Field Types - adding or changing a particular data type
• Function validation decorator
• Generic Models
• Other Model behaviour - construct(), pickling, private attributes, ORM mode
• Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

[samuelcolvin]

ye, the current dataclass implementation has a few problems, see changes in v1.10.2 and #4552.

I'm hoping we can strip away a lot of the logic in V2, see #4670.

But I'm not keen to carry on patching V1 dataclasses unless absolutely necessary. @PrettyWood has done an amazing job as far as possible, but the underlying approach has too many edge cases.

The real solution is to do it right in V2 as per #4670 I'd prefer to remove some features/functionality and have a simpler, more easily maintained implementation.

[dmontagu]

As far as I can tell from running the code snippet in the issue body, it seems it behaves correctly in v2 and is now fixed. If you notice any misbehavior in v2 feel free to open a new issue or request that we reopen this one.