///

Si tienes una app de FastAPI antigua con Pydantic v1, aquí te muestro cómo migrarla a Pydantic v2, y las **funcionalidades en FastAPI 0.119.0** para ayudarte con una migración gradual.

## Guía oficial { #official-guide }

Pydantic tiene una [Guía de migración](https://docs.pydantic.dev/latest/migration/) oficial de v1 a v2.

Y entonces el nuevo OpenAPI 3.1.0 se basó en la última versión (JSON Schema 2020-12) que incluía este nuevo campo `examples`.

Y ahora este nuevo campo `examples` tiene precedencia sobre el viejo campo único (y personalizado) `example`, que ahora está obsoleto.

[CORS o "Cross-Origin Resource Sharing"](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) se refiere a situaciones en las que un frontend que se ejecuta en un navegador tiene código JavaScript que se comunica con un backend, y el backend está en un "origen" diferente al frontend.

## Origen { #origin }

/// note | Detalles técnicos

En la especificación de OpenAPI se llama el [Objeto de Operación](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object).

///

Tiene toda la información sobre la *path operation* y se usa para generar la documentación automática.

Incluye los `tags`, `parameters`, `requestBody`, `responses`, etc.

En casi cualquier framework el manejo de la seguridad se convierte en un tema bastante complejo rápidamente.

Muchos paquetes que lo simplifican tienen que hacer muchos compromisos con el modelo de datos, la base de datos y las funcionalidades disponibles. Y algunos de estos paquetes que simplifican las cosas demasiado en realidad tienen fallos de seguridad en el fondo.

---

///

## Otro módulo con `APIRouter` { #another-module-with-apirouter }

Digamos que también tienes los endpoints dedicados a manejar "items" de tu aplicación en el módulo `app/routers/items.py`.

Tienes *path operations* para:

* `/items/`
* `/items/{item_id}`

Es toda la misma estructura que con `app/routers/users.py`.

Imaginemos que tienes algunos **modelos de machine learning** que quieres usar para manejar requests. 🤖

Los mismos modelos son compartidos entre requests, por lo que no es un modelo por request, o uno por usuario o algo similar.

Imaginemos que cargar el modelo puede **tomar bastante tiempo**, porque tiene que leer muchos **datos del disco**. Entonces no quieres hacerlo para cada request.

Esto significa que **cualquier valor** leído en Python desde una variable de entorno **será un `str`**, y cualquier conversión a un tipo diferente o cualquier validación tiene que hacerse en el código.

Aprenderás más sobre cómo usar variables de entorno para manejar **configuraciones de aplicación** en la [Guía del Usuario Avanzado - Ajustes y Variables de Entorno](./advanced/settings.md).

Si tienes este caso de uso específico usando SQLModel (o SQLAlchemy), podrías cerrar explícitamente la sesión después de que ya no la necesites:

{* ../../docs_src/dependencies/tutorial014_an_py310.py ln[24:28] hl[28] *}

De esa manera la sesión liberaría la conexión a la base de datos, para que otras requests puedan usarla.

Si no se especifica y la dependencia tiene `yield`, tendrá un `scope` de `"request"` por defecto.

### `scope` para sub-dependencias { #scope-for-sub-dependencies }