@Transactional ha aparecido en todos los ejemplos de las tres lecciones anteriores sin que la hayamos explicado. La hemos puesto en los servicios, la hemos necesitado en @Modifying, hemos dicho que el contexto de persistencia vive lo que dura la transacción, que el dirty checking guarda sin llamar a save() y que readOnly = true optimiza algo. Todo eso son afirmaciones pendientes de justificación. Esta lección las justifica.

Y va más allá, porque las transacciones son donde la corrección de CicloUrbana se juega de verdad. Iniciar un alquiler exige marcar la bicicleta como alquilada y crear el registro de alquiler: si ocurre lo primero sin lo segundo, una bicicleta queda bloqueada para siempre sin que nadie la tenga; si ocurre lo segundo sin lo primero, dos ciudadanos de Ribalta pueden alquilar la misma bicicleta. La transacción es lo que impide que exista un estado intermedio. Veremos también las dos trampas que hacen que @Transactional a veces no haga nada en absoluto, sin ningún aviso: son responsables de una cantidad desproporcionada de errores en producción.

1. Qué es una transacción: ACID en CicloUrbana
2. Gestión declarativa con @Transactional
3. Dónde se pone y por qué
4. Cómo funciona por dentro: el proxy AOP
5. Trampa 1: la autoinvocación
6. Trampa 2: los métodos no públicos
7. propagation: los siete valores
8. isolation: los cuatro niveles
9. readOnly, timeout y los atributos restantes
10. La regla del rollback
11. El contexto de persistencia y el flush
12. Bloqueo pesimista frente a optimista
13. TransactionTemplate: gestión programática
14. Eventos transaccionales
15. Transacciones y LazyInitializationException
16. Errores Comunes y Consejos
17. Ejercicios

Una transacción es una unidad de trabajo que se ejecuta entera o nada. Su definición clásica son las cuatro propiedades ACID, y conviene verlas sobre el caso real: iniciar un alquiler en la estación «Plaza Mayor».

Las tres operaciones marcadas deben ocurrir juntas.

La atomicidad se ve mejor con el contraejemplo. Sin transacción, cada operación de repositorio se confirma por separado: el UPDATE bicicletas SET estado='EN_USO' se confirma, y si el INSERT INTO alquileres falla después, la bicicleta RB-0142 queda EN_USO sin ningún alquiler que la respalde.

Ese estado inconsistente es especialmente dañino porque no produce ningún error visible: la bicicleta simplemente desaparece del inventario disponible y nadie sabe por qué. Con @Transactional, la excepción provoca un rollback y ambos cambios se deshacen.

Spring ofrece dos formas de gestionar transacciones: declarativa (una anotación) y programática (código explícito). La declarativa es la habitual porque separa la gestión de la lógica de negocio.

Es todo. Detrás de esa anotación ocurre lo siguiente: se obtiene una conexión del pool y se pone en autoCommit = false; se abre un contexto de persistencia asociado a la transacción; se ejecuta el método; si termina bien se hace flush y commit, y si lanza una excepción no comprobada, rollback; y finalmente se cierra el contexto y la conexión vuelve al pool.

Importa el import. Hay dos anotaciones con el mismo nombre:

En CicloUrbana usamos siempre la de Spring.

La respuesta corta: en la capa de servicio. La larga explica por qué no en las otras dos.

Por qué el servicio es la frontera correcta. Un caso de uso —«iniciar un alquiler»— es exactamente lo que debe ser atómico. Un método de repositorio es demasiado pequeño: si iniciar fuera la suma de tres transacciones independientes, no habría atomicidad. Un controlador es demasiado grande: incluye validación, mapeo y serialización, trabajo que no necesita una conexión abierta. El patrón recomendado, que ya usamos en 04-05:

Que lo por defecto sea readOnly = true tiene dos ventajas: optimiza todas las lecturas y convierte escribir en una decisión consciente, de modo que un método que se olvide de anotarse no escribirá por accidente.

Aquí está la clave para entender las dos trampas del apartado siguiente.

@Transactional no modifica tu código. Spring crea un proxy que envuelve tu bean —el mismo mecanismo de BeanPostProcessor de 02-03 y de los repositorios de 04-05—. Lo que se inyecta en el controlador no es tu AlquilerService: es un proxy que lo contiene.

Si el método lanza una excepción no comprobada, el proxy pide rollback en lugar de commit y la relanza.

Spring crea el proxy con JDK dinámico si el bean implementa interfaces, o con CGLIB generando una subclase si no; Spring Boot usa CGLIB por defecto (spring.aop.proxy-target-class=true), lo que explica el requisito de que los métodos transaccionales no sean final ni private.

La consecuencia fundamental: solo las llamadas que atraviesan el proxy activan la transacción. Una llamada de un método de la clase a otro de la misma clase va por this y no pasa por el proxy. De ahí la trampa 1.

Es el error más frecuente y el más difícil de detectar, porque no produce ningún síntoma hasta que algo falla a medias.

La llamada finalizarConTransaccion(id) es en realidad this.finalizarConTransaccion(id). this es el objeto real, no el proxy, así que la anotación se ignora por completo. Cada operación se autoconfirma como si no hubiera transacción, y un fallo a mitad del lote deja las devoluciones anteriores confirmadas y las siguientes sin hacer.

Ni el compilador ni Spring avisan. El código parece correcto.

Las tres soluciones, de mejor a peor. A. Extraer a otro bean (la recomendada):

Además de funcionar, suele mejorar el diseño: orquestar el lote y ejecutar la operación individual son responsabilidades distintas.

B. Autoinyección. Funciona y es fea: inyectar en la propia clase un campo @Lazy private final AlquilerService self —el proxy de sí misma— y llamar a self::finalizarConTransaccion. @Lazy es necesario para romper el ciclo de dependencia (02-02).

C. TransactionTemplate (apartado 13): gestión programática dentro del propio método, sin proxy de por medio. Esta trampa aplica igual a @Cacheable (09-02), @Async (07-03) y @PreAuthorize (05-05): toda anotación basada en proxies falla en la autoinvocación.

Con proxies CGLIB, Spring genera una subclase que sobrescribe los métodos: uno private no se puede sobrescribir, y protected o de paquete no se interceptan de forma fiable. La anotación se ignora en silencio. Desde Spring Framework 6.0 el arranque registra un aviso al detectarlo, lo que ayuda, pero la regla sigue siendo simple: @Transactional solo en métodos public, y nunca en métodos ni clases final.

propagation responde a: ¿qué hacer si ya hay una transacción en curso cuando se llama a este método?

Los tres que importan de verdad, con casos de CicloUrbana:

REQUIRED: el 95 % de los casos. AlquilerService.iniciar llama a BicicletaService.marcarAlquilada; ambos son @Transactional y el segundo se une a la transacción del primero: una sola transacción y un solo commit.

REQUIRES_NEW: registrar algo que debe sobrevivir a un rollback.

Si el intento de alquiler falla y la transacción principal hace rollback, el registro de auditoría se conserva, porque vivió en su propia transacción. Es exactamente lo que se quiere de una auditoría: registrar también lo que salió mal.

Su coste hay que conocerlo: REQUIRES_NEW usa una segunda conexión del pool mientras la primera sigue suspendida. Con maximum-pool-size: 10, diez peticiones concurrentes con REQUIRES_NEW agotan el pool y se produce un interbloqueo: cada hilo espera una conexión que otro hilo suspendido no soltará. Es una causa real y difícil de diagnosticar de caídas en producción.

NESTED: deshacer una parte sin perder el resto. Crea un punto de guardado dentro de la transacción actual; si falla, se vuelve a él y el resto sobrevive. Requiere soporte de JDBC —PostgreSQL lo tiene— pero no funciona con JpaTransactionManager, solo con DataSourceTransactionManager, lo que en la práctica lo descarta en aplicaciones JPA.

isolation controla cuánto puede una transacción ver del trabajo en curso de otras. Los fenómenos que se pueden producir:

Y los niveles que los previenen:

PostgreSQL usa READ_COMMITTED por defecto, y es el nivel correcto para prácticamente todo CicloUrbana. Dos particularidades suyas conviene saberlas: no implementa READ_UNCOMMITTED —pedirlo da READ_COMMITTED, porque nunca permite lecturas sucias— y su REPEATABLE_READ también evita los fantasmas, al estar implementado con instantáneas (MVCC), siendo más fuerte que lo que exige el estándar. Subirlo tiene sentido en un informe mensual que deba ver una foto coherente: @Transactional(isolation = Isolation.REPEATABLE_READ).

La regla práctica: no toques isolation salvo que sepas exactamente por qué. Subirlo aumenta los bloqueos y la probabilidad de errores de serialización que obligan a reintentar. Para el 99 % de los casos, READ_COMMITTED más el bloqueo optimista de @Version (04-03) es la combinación correcta.

readOnly = true no es una simple declaración de intenciones: Hibernate cambia el FlushMode a MANUAL y deja de hacer flush automático; se salta el dirty checking, sin guardar copias del estado original de cada entidad, lo que reduce notablemente la memoria en consultas de muchas filas; y marca la conexión JDBC como de solo lectura, lo que en algunas configuraciones permite dirigirla a una réplica. En una consulta que devuelve 10 000 entidades, no mantener 10 000 copias es un ahorro sustancial: por eso readOnly = true a nivel de clase es una buena práctica y no un adorno.

Ojo con una expectativa equivocada: readOnly no impide escribir. Con Hibernate, un INSERT explícito puede llegar a ejecutarse. Es una optimización, no una barrera de seguridad.

timeout limita la duración en segundos (@Transactional(timeout = 10)). Al superarse se lanza TransactionTimedOutException y se hace rollback. Es una red de seguridad valiosa, porque una transacción que se eternice retiene una conexión del pool y bloquea filas; en CicloUrbana tiene sentido en operaciones que puedan degenerar, como informes con filtros abiertos.

Por defecto, Spring hace rollback solo ante RuntimeException y Error. Las excepciones comprobadas confirman la transacción.

Es una herencia de EJB que sorprende a todo el mundo:

En CicloUrbana el problema no se plantea porque CicloUrbanaException, raíz de la jerarquía de 03-06, extiende RuntimeException. RecursoNoEncontradoException, EstacionLlenaException, BicicletaNoDisponibleException y las demás provocan rollback automáticamente. Fue una buena decisión de diseño y esta es una de las razones.

El error clásico: capturar la excepción y perder el rollback.

Capturar la excepción impide que llegue al proxy, y sin excepción el proxy hace commit. El alquiler se registra aunque el pago fallara.

Y una variante aún más desconcertante: si la excepción se lanza en un método interno también @Transactional (propagación REQUIRED) y se captura en el externo, la transacción ya quedó marcada para rollback por el interno, y al confirmar salta UnexpectedRollbackException: Transaction silently rolled back because it has been marked as rollback-only. Las dos soluciones correctas:

La A es preferible: el @RestControllerAdvice de 03-06 la convierte en un ProblemDetail con su código, y el cliente sabe qué pasó.

El contexto de persistencia vive exactamente lo que dura la transacción. Ese es el vínculo que hemos ido anunciando desde 04-01.

Cuándo hace Hibernate el flush, es decir, cuándo envía a la base de datos el SQL acumulado:

El flush automático antes de una consulta es más importante de lo que parece: guardar una estación nueva y consultar acto seguido existsByNombre devuelve true porque Hibernate vuelca el INSERT pendiente antes de ejecutar la consulta, aunque en el momento del save solo hubiera asignado el id.

El dirty checking, en detalle. Al cargar una entidad, Hibernate guarda una copia de su estado (la snapshot); en el flush compara campo a campo y genera un UPDATE solo si algo cambió, con solo las columnas modificadas si está activado el SQL dinámico.

Es correcto y es lo idiomático. Llamar a save() aquí es redundante.

El coste oculto del dirty checking: mantener la copia de cada entidad cargada consume memoria, y comparar todas en cada flush consume CPU. Por eso readOnly = true en las consultas es una optimización real.

En 04-03 añadimos @Version y vimos el bloqueo optimista. Aquí llega su complemento.

El caso donde el optimista no basta en CicloUrbana es la carrera por la última bicicleta de una estación: dos ciudadanos pulsan «alquilar» a la vez en «Plaza Mayor», ambas transacciones leen la misma bicicleta como DISPONIBLE y ambas la marcan como EN_USO. Con @Version, el segundo commit falla con un 409, lo cual es correcto pero mala experiencia: el usuario recibe un error cuando podríamos haberle asignado otra bicicleta.

El bloqueo pesimista lo evita serializando el acceso:

Genera un SELECT ... FOR UPDATE: la fila queda bloqueada hasta el fin de la transacción y la segunda espera. Cuando el primero confirma, el segundo relee, ve que ya no está disponible y busca otra. Nadie recibe un 409.

Los modos disponibles: PESSIMISTIC_READ (bloqueo compartido: otros leen, no escriben), PESSIMISTIC_WRITE (exclusivo, SELECT ... FOR UPDATE), PESSIMISTIC_FORCE_INCREMENT (exclusivo y además incrementa @Version), OPTIMISTIC (comprueba la versión al final) y OPTIMISTIC_FORCE_INCREMENT (la incrementa aunque nada cambie).

Tres reglas para el bloqueo pesimista: fija siempre un timeout, porque sin él una transacción larga puede bloquear a las demás indefinidamente; mantén la transacción lo más corta posible, ya que el bloqueo dura hasta el commit; y bloquea las filas siempre en el mismo orden en todos los métodos, o dos transacciones que bloqueen A→B y B→A producirán un interbloqueo que PostgreSQL resolverá matando una de ellas.

El criterio de elección: optimista por defecto —es lo que llevan Estacion, Bicicleta y Alquiler—, y pesimista solo en los puntos concretos de alta contención sobre un recurso escaso.

Cuando la anotación no encaja —control fino del alcance, transacciones dentro de un bucle, o para esquivar la autoinvocación—, TransactionTemplate da control explícito:

Este caso —importar el catálogo de estaciones de Ribalta desde un CSV con filas potencialmente erróneas— es el ejemplo canónico: con @Transactional en el método, un solo error anularía la importación entera; con una transacción por fila se importa lo válido y se registra lo descartado.

La regla: @Transactional por defecto; TransactionTemplate cuando la anotación no llega.

En 02-02 publicamos el evento AlquilerIniciado. Un @EventListener normal se ejecuta de forma síncrona y dentro de la transacción, lo que produce dos problemas graves.

Problema 1: se notifica algo que puede no ocurrir. Si el escuchador envía un correo y después la transacción hace rollback, el correo anuncia un alquiler que no existe. Problema 2: se retiene una conexión durante la llamada externa. Cobrar en la pasarela puede tardar dos segundos, y durante todo ese tiempo la conexión sigue prestada: la causa de agotamiento del pool que analizamos en 04-02.

@TransactionalEventListener resuelve ambos:

Dos advertencias importantes. En AFTER_COMMIT la transacción ya terminó: si el escuchador intenta escribir en la base de datos necesita @Transactional(propagation = REQUIRES_NEW), y sin eso los cambios se pierden en silencio. Y sigue siendo síncrono por defecto, ejecutándose en el mismo hilo después del commit pero antes de responder al cliente; para no retrasar la respuesta, combínalo con @Async (07-03).

Aplicado a CicloUrbana, el cobro del alquiler pasa a ocurrir después del commit, con la conexión ya devuelta al pool: ese cambio por sí solo puede multiplicar la capacidad de la aplicación.

Cerramos el círculo abierto en 04-04. Con open-in-view: false (04-02), el contexto de persistencia muere con la transacción del servicio. Todo lo que salga de ahí está separado.

Esto convierte la regla de 03-05 —«el servicio devuelve DTOs, no entidades»— de buena práctica en requisito técnico. Las tres decisiones del módulo encajan aquí: LAZY en todas las asociaciones (04-04), open-in-view: false (04-02) y mapeo dentro de la transacción. Juntas garantizan que ninguna consulta se dispare por accidente durante la serialización.

Llamar a un método @Transactional desde la misma clase. La anotación se ignora sin ningún aviso. Extrae a otro bean.

Poner @Transactional en métodos privados o final. No se interceptan. Solo métodos public en clases no final.

Capturar una excepción y no relanzarla. El commit se produce igualmente, o aparece UnexpectedRollbackException. Relanza como excepción del dominio.

Esperar rollback con excepciones comprobadas. Por defecto no lo hay. En CicloUrbana no es problema porque todo hereda de RuntimeException.

Hacer llamadas externas dentro de la transacción. Retiene una conexión durante toda la llamada de red. Usa @TransactionalEventListener(AFTER_COMMIT).

Abusar de REQUIRES_NEW. Consume una segunda conexión mientras la primera está suspendida; con concurrencia agota el pool y produce interbloqueos.

Subir el isolation «por seguridad». Aumenta bloqueos y errores de serialización. READ_COMMITTED más @Version cubre casi todo.

Consejo: @Transactional(readOnly = true) en la clase de servicio. Optimiza todas las lecturas y hace que escribir sea una decisión consciente.

Consejo: transacciones cortas. Cada milisegundo de transacción es un milisegundo de conexión prestada y de filas bloqueadas. Valida antes de abrirla y notifica después de cerrarla.

Consejo: comprueba que la transacción está activa. Con logging.level.org.springframework.transaction: DEBUG verás los mensajes Creating new transaction e Initiating transaction commit; si no aparecen donde esperabas, casi seguro es la trampa 1.

Implementa AlquilerService.finalizar(Long alquilerId, FinalizarAlquilerRequest peticion). Debe: verificar que el alquiler existe y está en curso; comprobar que la estación de destino tiene hueco (si no, EstacionLlenaException); calcular el importe con CalculadoraTarifa; marcar la bicicleta como DISPONIBLE en la estación de destino; cerrar el alquiler; y notificar al usuario solo si todo se confirmó. Justifica cada decisión transaccional.

Para cada operación de CicloUrbana, decide entre bloqueo optimista, pesimista o ninguno, y justifícalo.

1. Editar el nombre de una estación desde el panel del ayuntamiento.
2. Alquilar la última bicicleta disponible de una estación en hora punta.
3. Consultar el listado público de estaciones.
4. Descontar saldo del monedero de un usuario al finalizar un alquiler.

Solución 1.

Las decisiones transaccionales, una a una:

• @Transactional sin readOnly, porque escribe en tres entidades: la clase declara readOnly = true y este método lo sobrescribe, de modo que escribir es una decisión explícita.
• Todo en una sola transacción. Cerrar el alquiler, liberar la bicicleta y asignarla a la estación deben ocurrir juntos; si el UPDATE del alquiler fallara tras cambiar la bicicleta, esta quedaría DISPONIBLE sin estar aparcada en ningún sitio.
• Sin save(): las tres entidades están gestionadas y el dirty checking genera los UPDATE en el commit.
• Las excepciones son de CicloUrbanaException, no comprobadas, así que provocan rollback y el @RestControllerAdvice de 03-06 las convierte en 409 o 404 con ProblemDetail.
• La notificación va en AFTER_COMMIT: enviarla dentro retendría la conexión durante la llamada al servicio de correo y podría anunciar un alquiler que después se deshace.
• El mapeo a DTO ocurre dentro de la transacción, requisito con open-in-view: false. Y sin bloqueo pesimista, porque @Version en Alquiler basta: dos usuarios no finalizan el mismo alquiler a la vez.

Solución 2. Los cuatro fallos:

1. Autoinvocación (el más grave). procesarBicicleta(bici) se llama con this, sin pasar por el proxy, así que REQUIRES_NEW se ignora por completo y todo se ejecuta en la transacción externa.

2. @Transactional en un método private. No es interceptable: aunque se corrigiera la autoinvocación, seguiría sin funcionar. Debe ser public y vivir en otro bean.

3. Excepción capturada y no relanzada. Si el save falla, se registra en el log y el bucle continúa: la transacción externa confirma y se dan por procesadas bicicletas que no lo están. Y si el fallo hubiera marcado la transacción para rollback, el commit final daría UnexpectedRollbackException.

4. Llamada externa dentro de la transacción. servicioExterno.notificarTaller(...) retiene la conexión durante toda la llamada de red; en una revisión nocturna sobre cientos de bicicletas, la transacción puede durar minutos con una conexión bloqueada.

Un quinto problema de diseño: cargar todas las bicicletas para modificarlas una a una es innecesario, ya que una consulta @Modifying (04-06) lo haría en una sola sentencia. Versión corregida:

revisionNocturna ya no es transaccional: solo orquesta. Cada bicicleta se procesa en su propia transacción, un fallo individual no arrastra al resto y la notificación al taller viaja en un evento que se atiende fuera de cualquier transacción.

Solución 3.

1. Optimista (@Version). Los conflictos son raros —dos administrativos editando la misma estación a la vez— y el 409 con «recarga y vuelve a intentarlo» es una respuesta perfectamente aceptable. Bloquear la fila penalizaría a todas las lecturas concurrentes sin ganancia real.
2. Pesimista (PESSIMISTIC_WRITE con timeout). Es el caso de contención real: en hora punta, varios ciudadanos compiten por el mismo recurso escaso. Con optimista, todos menos uno reciben un 409 innecesario cuando el sistema podría asignarles otra bicicleta. El SELECT ... FOR UPDATE serializa el acceso y cada usuario obtiene una bicicleta o un mensaje honesto de que no quedan.
3. Ninguno. Es una lectura pura: @Transactional(readOnly = true) y ningún bloqueo. Cualquier bloqueo aquí sería puro coste.
4. Pesimista. El saldo de un monedero es el ejemplo canónico de actualización perdida: leer 12,50 €, restar 1,75 € y escribir 10,75 € desde dos transacciones concurrentes hace desaparecer uno de los descuentos. El optimista lo detectaría, pero fallar un cobro ya realizado es peor que esperar unos milisegundos. Mejor aún es evitar la lectura previa con un UPDATE atómico —update Monedero m set m.saldo = m.saldo - :importe where m.id = :id and m.saldo >= :importe—, que resuelve la carrera sin bloquear nada.

Ya sabes qué hace realmente @Transactional, y era mucho más de lo que la anotación aparenta. Entiendes las cuatro propiedades ACID sobre el caso concreto de iniciar un alquiler en Ribalta, donde marcar la bicicleta y crear el registro deben ocurrir juntos o ninguno, y has visto que el estado inconsistente más peligroso es el que no produce ningún error. Sabes que la anotación va en la capa de servicio —no en el controlador, donde retendría la conexión durante la serialización, ni en el repositorio, cuyos métodos son demasiado pequeños para ser un caso de uso— y usas el patrón de readOnly = true en la clase con @Transactional explícito en los métodos que escriben, para que escribir sea siempre una decisión consciente.

Conoces el mecanismo del proxy AOP y, con él, las dos trampas que hacen que la anotación no haga absolutamente nada: la autoinvocación, porque una llamada por this no atraviesa el proxy, y los métodos no públicos, que CGLIB no puede interceptar. Ambas fallan en silencio, y su solución —extraer a otro bean— casi siempre mejora también el diseño. Manejas los siete valores de propagation sabiendo que REQUIRED cubre el 95 % de los casos, que REQUIRES_NEW es la respuesta correcta para una auditoría que debe sobrevivir al rollback pero consume una segunda conexión que puede agotar el pool, y que NESTED no es viable con JpaTransactionManager. Sitúas los cuatro niveles de isolation frente a los tres fenómenos de concurrencia, sabes que PostgreSQL usa READ_COMMITTED por defecto y no implementa lecturas sucias, y tienes claro que subir el nivel «por seguridad» compra bloqueos, no corrección.

Dominas la regla del rollback: por defecto solo con excepciones no comprobadas, algo que en CicloUrbana no da problemas porque toda la jerarquía de 03-06 hereda de RuntimeException; y reconoces el error clásico de capturar la excepción y quedarse sin rollback, junto con su variante desconcertante, la UnexpectedRollbackException. Sabes cuándo hace flush Hibernate y por qué el dirty checking hace innecesario llamar a save() sobre una entidad gestionada, así como el coste en memoria que readOnly = true evita. Distingues el bloqueo optimista del pesimista y sabes elegir: @Version por defecto, SELECT ... FOR UPDATE con timeout en la carrera por la última bicicleta de «Plaza Mayor». Usas TransactionTemplate cuando la anotación no llega —una transacción por fila al importar el catálogo de estaciones— y has sacado el cobro y las notificaciones fuera de la transacción con @TransactionalEventListener(AFTER_COMMIT), devolviendo la conexión al pool antes de hacer nada lento. En sistemas distribuidos esta atomicidad deja de estar disponible y hay que recurrir a patrones como saga, que veremos en 07-05.

Queda un cabo suelto que arrastramos desde 04-02: el esquema. ddl-auto: update sigue creando tablas por su cuenta, nadie sabe exactamente qué SQL se ha ejecutado sobre la base de datos y eso no puede llegar a producción. La lección 04-08, Migraciones de Esquema con Flyway, cierra el módulo: veremos por qué el esquema debe versionarse como código, la convención de nombres de los scripts y la tabla flyway_schema_history con sus checksums, escribiremos el esquema inicial completo de CicloUrbana en SQL de PostgreSQL —coherente con las entidades y relaciones de 04-03 y 04-04— y la migración de datos que jubila al CargadorEstacionesDemo del módulo 1, y aprenderemos el patrón expand/contract para renombrar una columna sin parar el servicio.