Una operación que modifica cientos de registros puede ser correcta según sus reglas y, aun así, afectar más datos de los esperados. Una confirmación genérica —«¿Está seguro?»— no permite valorar el alcance ni detectar condiciones inesperadas. Una vista previa de cambios en PHP debe mostrar qué registros se verían afectados, qué valores cambiarían y bajo qué condiciones se podría ejecutar la operación.
La vista previa reduce sorpresas, pero no garantiza que la ejecución posterior vaya a producir exactamente el mismo resultado. Entre ambas fases pueden cambiar los datos, los permisos o el alcance de la operación. El diseño debe hacer visible esa incertidumbre y volver a validar lo necesario antes de escribir.
Cuándo aporta valor una vista previa
Conviene considerar una vista previa para operaciones masivas, sensibles o difíciles de revertir: actualizar precios, cambiar estados, reasignar cuentas, eliminar información o recalcular datos derivados. También resulta útil cuando la persona que inicia la tarea necesita revisar su impacto o conseguir aprobación antes de ejecutarla.
No todas las acciones necesitan una interfaz de previsualización. Si una operación es pequeña, reversible y tiene un resultado inequívoco, puede bastar una confirmación contextual. En cambio, si el usuario no puede saber qué significa confirmar, el problema requiere mostrar datos concretos, no añadir otro cuadro de diálogo.
La vista previa tampoco sustituye una copia de seguridad, un mecanismo de reversión ni una política de aprobación. Si un error puede tener consecuencias graves, hay que valorar controles adicionales, como una aprobación por otra persona, una ejecución gradual o un proceso de recuperación probado.
Separar el cálculo de la aplicación
La regla de negocio debe poder calcular una propuesta sin modificar la base de datos. Una estrategia práctica es compartir la selección y el cálculo entre dos modos: uno que describe el cambio y otro que lo aplica. Evitar dos implementaciones independientes reduce el riesgo de que la vista previa y la ejecución interpreten reglas distintas.
La propuesta puede incluir, por cada elemento afectado:
- Un identificador que permita reconocer el registro.
- Los valores relevantes actuales y los valores esperados.
- El motivo por el que se incluye o se excluye.
- Las validaciones realizadas y los conflictos detectados.
- El alcance de la operación, como filtros, cuenta o intervalo temporal.
Por ejemplo, una operación para cambiar el estado de pedidos puede mostrar el estado actual, el estado propuesto y la razón de elegibilidad. Si hay demasiados elementos para presentarlos todos en pantalla, se pueden ofrecer totales y una muestra, siempre aclarando qué se está mostrando y permitiendo inspeccionar o exportar el detalle cuando sea necesario.
En PHP, conviene encapsular la selección y el cálculo en componentes con responsabilidades claras. Un servicio de dominio puede producir cambios propuestos; otro componente puede presentarlos; y una ruta de aplicación puede encargarse de validar y persistirlos. La vista previa no debería ejecutar indirectamente una escritura por efectos secundarios de la lectura.
Validar datos, permisos y alcance
Una propuesta útil explica no solo qué cambiaría, sino por qué puede cambiarse. Valida las condiciones de negocio sobre los datos actuales y comprueba que el usuario tenga permiso para ver y ejecutar esa operación. Tener permiso para consultar registros no implica necesariamente tener permiso para modificarlos.
El alcance debe quedar explícito. Si la acción depende de filtros, una selección o una carga de archivo, registra esos parámetros de forma comprensible y comunica límites, exclusiones y errores. Evita que una búsqueda amplia o un filtro omitido conviertan accidentalmente una acción limitada en una modificación global.
También hay que señalar qué no puede preverse con certeza. La vista previa no anticipa automáticamente cambios realizados por otros procesos, reglas que se ejecuten en sistemas externos ni efectos secundarios que dependan del estado futuro. Si hay integraciones, colas o cálculos posteriores, describe esos efectos por separado y no los presentes como parte confirmada del resultado.
Evitar aplicar una propuesta obsoleta
Una vista previa representa los datos en un momento concreto. Si cambian antes de la ejecución, un pedido puede dejar de cumplir las condiciones, un usuario puede perder permisos o un registro puede haber sido actualizado por otro proceso. Por eso, no debe tratarse el resultado mostrado como una autorización permanente para escribir.
Al ejecutar, vuelve a comprobar las condiciones que determinan la elegibilidad y los permisos. Según el caso, puedes comparar una versión del registro, una marca de tiempo o los valores relevantes con los observados al calcular la propuesta. Si hay discrepancias, no apliques silenciosamente una decisión distinta: informa del conflicto y pide generar una nueva vista previa o resolverlo de forma explícita.
En procesos que exigen una correspondencia estricta, conserva una referencia a la propuesta y valida que la aplicación siga usando su alcance y sus reglas. Una transacción puede proteger un conjunto de escrituras frente a fallos intermedios, pero no elimina por sí sola el tiempo transcurrido entre la previsualización y la ejecución. La estrategia de concurrencia debe corresponder al riesgo y al volumen de la operación.
Ejecutar por lotes y registrar resultados
Para volúmenes grandes, aplicar todo en una sola operación puede aumentar el tiempo de bloqueo y dificultar la recuperación. Define límites de lote apropiados para la base de datos y el comportamiento de la aplicación. Si hay fallos parciales, el usuario debe poder distinguir los registros aplicados, los omitidos y los que requieren revisión.
Registra información suficiente para investigar el resultado: quién inició y aprobó la operación, cuándo se preparó y ejecutó, qué alcance se solicitó, cuántos elementos se procesaron y qué errores ocurrieron. Evita guardar datos personales o valores sensibles sin necesidad; los registros de auditoría también deben respetar los controles de acceso y retención aplicables.
Si la operación se reintenta, considera la idempotencia: repetir una solicitud no debería duplicar efectos inesperados. Un identificador de operación y estados de ejecución pueden ayudar a reconocer solicitudes repetidas y separar preparación, aprobación, ejecución y finalización. No presentes el despliegue del código como equivalente a liberar o habilitar la operación: son decisiones distintas y deben tener controles propios.
Probar que la vista previa no modifica datos
Las pruebas deben comprobar tanto el cálculo como la ausencia de escrituras en modo de previsualización. Usa datos representativos para verificar inclusiones, exclusiones, valores actuales y propuestos, permisos insuficientes y validaciones fallidas.
Comprueba además que la ejecución aplica la propuesta esperada y que los cambios concurrentes producen el comportamiento definido. Prueba fallos dentro de un lote, reintentos y errores de integración cuando correspondan. Las pruebas de integración con la base de datos son importantes: un test unitario del cálculo no demuestra que una ruta de previsualización carezca de efectos secundarios.
Los casos límite deben incluir filtros vacíos, grandes volúmenes, registros eliminados o modificados entre fases y usuarios con distintos ámbitos de acceso. También conviene verificar que la interfaz no afirme «se actualizarán exactamente estos elementos» si la aplicación volverá a calcular el conjunto en el momento de ejecución.
Lista de comprobación para decidir el control necesario
- ¿La operación afecta a muchos registros, tiene efectos difíciles de revertir o requiere aprobación?
- ¿Se muestran el alcance, los elementos afectados y los valores actuales y esperados?
- ¿La previsualización está separada de las escrituras y sus efectos secundarios?
- ¿Se validan permisos, reglas de negocio y datos tanto al preparar como al ejecutar?
- ¿Se detectan cambios relevantes ocurridos entre ambas fases?
- ¿Hay límites de lote, un tratamiento definido de fallos parciales y registros de auditoría proporcionados?
- ¿Las pruebas confirman que previsualizar no modifica datos y que ejecutar respeta el resultado validado?
Una vista previa es adecuada cuando ayuda a tomar una decisión informada y sus límites están claros. Si no puede ofrecerse una estimación fiable del impacto, es preferible reducir el alcance, ejecutar primero en un entorno controlado o exigir una revisión adicional, en lugar de convertir una cifra o una lista parcial en una promesa de resultado.
