# Migra de Pydantic v1 a Pydantic v2 { #migrate-from-pydantic-v1-to-pydantic-v2 }

Si tienes una app de FastAPI antigua, podrías estar usando Pydantic versión 1.

FastAPI ha tenido compatibilidad con Pydantic v1 o v2 desde la versión 0.100.0.

Si tenías instalado Pydantic v2, lo usaba. Si en cambio tenías Pydantic v1, usaba ese.

Imaginemos que queremos tener una dependencia que revise si el parámetro de query `q` contiene algún contenido fijo.

Pero queremos poder parametrizar ese contenido fijo.

## Una *instance* "callable" { #a-callable-instance }

En Python hay una forma de hacer que una instance de una clase sea un "callable".

No la clase en sí (que ya es un callable), sino una instance de esa clase.

### Modelo para Salida { #model-for-output }

Pero si usas el mismo modelo como salida, como aquí:

{* ../../docs_src/separate_openapi_schemas/tutorial001_py310.py hl[19] *}

...entonces, porque `description` tiene un valor por defecto, si **no devuelves nada** para ese campo, aún tendrá ese **valor por defecto**.

### Modelo para Datos de Response de Salida { #model-for-output-response-data }

///

### Acerca de `**user_in.dict()` { #about-user-in-dict }

#### `.dict()` de Pydantic { #pydantics-dict }

`user_in` es un modelo Pydantic de la clase `UserIn`.

Los modelos Pydantic tienen un método `.dict()` que devuelve un `dict` con los datos del modelo.

Así que, si creamos un objeto Pydantic `user_in` como:

```Python

/// tip | Consejo

Si llamas manualmente a `app.openapi()`, deberías actualizar los `operationId`s antes de eso.

///

/// warning | Advertencia

Si haces esto, tienes que asegurarte de que cada una de tus *path operation functions* tenga un nombre único.

Incluso si están en diferentes módulos (archivos de Python).

///

///

Si en tu caso de uso no hay problema en ejecutar esos pasos previos **múltiples veces en paralelo** (por ejemplo, si no estás ejecutando migraciones de base de datos, sino simplemente verificando si la base de datos está lista), entonces también podrías simplemente ponerlos en cada contenedor justo antes de iniciar el proceso principal.

La mayoría de estas ideas serían más o menos **independientes**, y en la mayoría de los casos solo deberías estudiarlas si aplican directamente a **tu proyecto**.

Si algo parece interesante y útil para tu proyecto, adelante y revísalo, pero de lo contrario, probablemente puedas simplemente omitirlas.

/// tip | Consejo

Los parámetros de la función se reconocerán de la siguiente manera:

* Si el parámetro también se declara en el **path**, se utilizará como un parámetro de path.
* Si el parámetro es de un **tipo singular** (como `int`, `float`, `str`, `bool`, etc.), se interpretará como un parámetro de **query**.
* Si el parámetro se declara como del tipo de un **modelo de Pydantic**, se interpretará como un **request body**.

* <a href="https://www.python-httpx.org" target="_blank"><code>httpx</code></a> - Requerido si deseas usar el `TestClient`.
* <a href="https://jinja.palletsprojects.com" target="_blank"><code>jinja2</code></a> - Requerido si deseas usar la configuración de plantilla por defecto.

Queremos obtener el `current_user` *solo* si este usuario está activo.

Entonces, creamos una dependencia adicional `get_current_active_user` que a su vez utiliza `get_current_user` como dependencia.

Ambas dependencias solo devolverán un error HTTP si el usuario no existe, o si está inactivo.

Así que, en nuestro endpoint, solo obtendremos un usuario si el usuario existe, fue autenticado correctamente, y está activo: