Subfields are not snake_cased

[jettdc]

We have the following definition (for example)

class FieldSchema(pydantic.BaseModel):
    nullable: pydantic.StrictBool
    data_type: FieldDataType = pydantic.Field(alias="dataType")
    ...

you currently can only instantiate it like:

FieldSchema(nullable=False, dataType=...)

where you should be able to do

FieldSchema(nullable=False, data_type=...)

not sure why this is, since it does look like you should be able to use the snake_case and the alias should just be used for serialization, but both the intellisense shows the camelCase and the code fails to "compile" when using the snake_case

[jsmith]

By default, Pydantic uses the alias (if provided) to create the __init__() method. In the model config, we could set populate_by_name to True to allow either the field name or alias to be used. This only solves party of the challenge though since the type definition seems to continue to use the alias meaning code assist and type checkers won't know about the existence of the additional parameters.

To resolve this issue, it seems like the solution is to use pydantic extensions (e.g. see the mypy extension).

I would need to look into this more before I can decide on a solution. I think we should first decide whether we want to continue to only promote dictionaries as the way to pass inputs or whether we should support both dictionaries and classes in a first class manner (so essentially decide about whether to support the pattern you use in #50). If we decide to support classes, we should determine a better solution for this issue since I'd like users to use the snake case names rather than the camel case names.