Posts

git rebase --onto parece una variante complicada de git rebase. Durante mucho tiempo lo evité por esa razón. Sin embargo, esta opción responde a una pregunta muy concreta: ¿cómo se mueve solo una parte de una rama a una base nueva sin arrastrar los commits que están debajo? Este caso aparece cuando una rama se creó desde la rama equivocada, cuando hay que reorganizar una pila de ramas o cuando varios commits útiles están atrapados en medio de un historial. Un rebase normal decide de forma implícita qué debe repetir. Con --onto, se definen explícitamente la base nueva, el límite de los commits que se excluyen y la rama que se mueve. ...

Django 6.1 incorpora dos cambios del ORM con un objetivo común: dejar que la base de datos haga trabajo útil sin volver opaca la aplicación. Los fetch modes cambian lo que ocurre cuando un campo se carga bajo demanda. DB_CASCADE mueve una eliminación en cascada de Python a una restricción SQL. Ambos pueden eliminar mucho trabajo, pero activarlos sin examinar sus efectos secundarios es arriesgado. Las notas de la versión Django 6.1 presentan estas API como optimizaciones. En la práctica, cambian dónde se realiza el trabajo. Ese es el punto clave antes de actualizar. ...

¿select_related() o prefetch_related()? Ambos métodos eliminan consultas N+1 en Django, pero no generan en absoluto el mismo SQL. El primero añade un join a la consulta principal. El segundo ejecuta varias consultas y después relaciona los objetos en Python. La elección correcta depende menos del volumen de datos que del tipo de relación recorrida. Para entenderlo, partamos de un modelo deliberadamente sencillo: from django.conf import settings from django.db import models class Post(models.Model): title = models.CharField(max_length=200) author = models.ForeignKey( settings.AUTH_USER_MODEL, on_delete=models.CASCADE, related_name="posts", ) tags = models.ManyToManyField("Tag", related_name="posts") class Comment(models.Model): post = models.ForeignKey( Post, on_delete=models.CASCADE, related_name="comments", ) body = models.TextField() is_public = models.BooleanField(default=True) author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE) class Tag(models.Model): name = models.CharField(max_length=50) Desde un Post, author designa como máximo a un usuario. En cambio, comments y tags pueden contener varios objetos. Esta diferencia de cardinalidad dicta casi siempre qué método utilizar. ...

GitOps casi siempre se presenta con Kubernetes de fondo: ArgoCD, Flux, manifests por centenares. El resultado es que muchos equipos que despliegan en un simple VPS con Docker Compose asumen que el modelo no va con ellos. Siguen desplegando por SSH: git pull, docker compose up -d, cruzando los dedos para que nadie se salte un paso. Es una lástima, porque el núcleo de GitOps no tiene nada que ver con Kubernetes. Y desde hace un tiempo existe una herramienta que cubre exactamente ese hueco: doco-cd, un motor de despliegue continuo para Docker Compose. Combinado con SOPS y age para cifrar los secretos directamente en el repo, se obtiene GitOps sin Kubernetes: un pipeline completo donde desplegar se reduce a un git push. Este artículo explica el principio y luego recorre la puesta en marcha en un proyecto Django con varios ficheros compose. ...

El TDD provoca dos reacciones extremas. La primera: “ya escribo tests, entonces hago TDD”. La segunda: “escribir los tests antes solo invierte el esfuerzo sin ganar mucho”. Ambas pasan por alto lo que realmente es el TDD. No es una cuestión de cobertura ni una simple inversión de orden. Es una disciplina de diseño que obliga a explicitar una intención antes de escribir el código que la satisface. Este artículo abre una serie sobre TDD. Antes de comparar las escuelas (Chicago, Londres, ATDD doble bucle, TDD estricto), hay que asentar el tronco común: el ciclo Rojo-Verde-Refactor, la práctica de los baby steps y las propiedades FIRST que definen un test que merece ese nombre. Los artículos siguientes partirán de esta base para hacer los compromisos tangibles, con ejemplos concretos. ...

Los cuatro artículos anteriores de la serie pusieron las bases para que un sistema distribuido se mantenga coherente: Saga para orquestar workflows, Outbox para publicar eventos fiables, Inbox para consumirlos sin duplicados, Idempotency Keys para proteger la API. Queda una pregunta: ¿qué se hace con los eventos una vez publicados? La respuesta más frecuente es: se usan para construir vistas de lectura. Es exactamente lo que propone el patrón CQRS (Command Query Responsibility Segregation): separar el modelo de escritura del modelo de lectura, cuando ambos divergen lo suficiente como para que forzarlos en una misma estructura cueste más que duplicarlos. ...

Los dos artículos anteriores trataron la idempotencia del lado evento: el patrón Outbox garantiza que un mensaje se publica al menos una vez, y el patrón Inbox garantiza que solo se consume una vez. Queda un tercer lugar donde aparece el mismo problema, más arriba: la propia API HTTP. Cuando un cliente lanza un POST /api/payments y su conexión se cae antes de recibir la respuesta, no sabe si el pago se creó o no. Si reintenta, arriesga pagar dos veces. Si no reintenta, arriesga no pagar nada. El patrón Idempotency Key, popularizado por Stripe y adoptado desde por la mayoría de APIs de pago, resuelve ese dilema poniendo el control del retry en manos del cliente. ...

El artículo anterior sobre el Transactional Outbox estableció una garantía clara: todo evento escrito en base acabará siendo publicado. Esa garantía es intencionadamente at-least-once. Un consumidor puede recibir el mismo evento dos veces, tres veces, o más si la red se porta mal. El patrón Outbox nunca promete unicidad. La consecuencia es inmediata: si el consumidor aplica dos veces el efecto del mensaje, factura dos veces, envía dos correos, descuenta stock dos veces. La coherencia garantizada del lado productor se rompe del lado lector. ...

Cuando un servicio modifica su base y quiere avisar al resto del sistema enviando un evento a Kafka, RabbitMQ o SQS, el código ingenuo se parece a esto: escribir en base y luego publicar. Si la publicación falla tras el commit, el evento se pierde. Si la publicación tiene éxito pero el commit falla, el evento habla de un estado que no existe. Ambos casos son la definición del dual-write problem. ...

Una operación de negocio que toca varios servicios plantea una pregunta que SQL resuelve desde hace cincuenta años dentro de una sola base de datos: ¿qué pasa cuando un paso tiene éxito y el siguiente falla? Mientras todo vive en la misma base, BEGIN ... ROLLBACK basta. En cuanto llamas a un servicio externo, una API de terceros u otra base de datos, esa red de seguridad desaparece. El patrón Saga responde a esa pregunta. En lugar de intentar una transacción ACID imposible, divide la operación en pasos locales, cada uno acompañado de una transacción compensatoria que sabe deshacer su efecto. Si el paso 4 falla, las compensaciones de los pasos 1, 2 y 3 se reproducen en orden inverso. ...