Introducción
Una pequeña tienda está añadiendo puntos de recogida. Su proceso de compra antiguo proporciona el ID de pedido, el cliente, los centavos enteros y una nota; uno nuevo proporciona también un código de recogida. Los pedidos existentes y sus relaciones con los artículos deben seguir siendo utilizables. Un valor predeterminado mantiene la compatibilidad cuando se omite una columna, pero no nos dice dónde eligió realmente recoger su pedido un cliente histórico.
Entregarás expand.sql y una tabla real de pedidos ampliada, usarás ambos clientes preparados y después observarás el límite real entre las transacciones de datos y el DDL de MySQL. Se requieren conocimientos básicos para moverse por la terminal y de SELECT/WHERE, INSERT/UPDATE, columnas, claves primarias y valores predeterminados en MySQL. No se requiere Python ni desarrollo de aplicaciones. Esta unidad independiente proporciona su propio Oracle MySQL privado y Terminal; el servicio genérico de base de datos no está relacionado.
Trabaja solo en /home/labex/project/pickup-desk. Puedes añadir la columna de recogida documentada a orders y actualizar o ampliar únicamente la tabla aislada ddl_demo para la demostración. Conserva todos los ID originales de pedido, los clientes, los importes, las notas, los artículos, los puntos y las tablas de aprobaciones, además de las herramientas proporcionadas. Solo se pueden añadir los tres pedidos de práctica indicados a continuación. Esta es una ventana de mantenimiento controlada; no es una migración en línea ni libre de bloqueos ni de interrupciones. La estimación de tiempo del autor incluye lectura y errores habituales; no se ha cronometrado con principiantes.
Ampliar el esquema manteniendo operativos ambos clientes
En este paso, crearás un pedido normal con el cliente antiguo, añadirás una columna de recogida compatible y leerás pedidos reales creados por ambas versiones del cliente.
Empieza en Terminal, en el indicador del intérprete del sistema. cd cambia el directorio actual; la ruta absoluta funciona desde cualquier directorio inicial. ./shop ejecuta un comando preparado de ese directorio. Son comandos del intérprete del sistema, no entradas en un indicador de MySQL:
cd /home/labex/project/pickup-desk
./shop status
./shop points
Las cabeceras originales son 101 / Sam / 2100, 102 / Sam / 3400 y 103 / Lee / 0, con sus propias notas y artículos. Los dos pedidos de Sam son identidades diferentes. Los importes son centavos enteros y cero es válido. status y show leen valores realmente almacenados; nunca migran un registro ni sustituyen una elección de recogida.
El cliente antiguo preparado acepta old order_id customer total_cents sku quantity. Inserta una cabecera usando nombres explícitos de columnas antiguas y un artículo en la misma transacción nativa. Una llamada correcta confirma la transacción; un error SQL nativo detiene el lote y cierra su conexión, revirtiendo los cambios de datos pendientes. Crea el pedido normal permitido y léelo después:
./shop old 201 Mina 1600 MUG 1
./shop show 201
Su cabecera contiene el ID 201, Mina, 1600 y Created by legacy client; su detalle contiene MUG, cantidad 1. El valor devuelto pickup_column: false indica que este campo no está desplegado. El cliente nuevo tiene los mismos argumentos seguidos de un código de recogida. El comando siguiente debe fallar deliberadamente con el error nativo 1054, columna desconocida pickup_code, y un estado de salida distinto de cero. No debe dejar ninguna cabecera ni detalle:
./shop new 203 Pia 1900 CARD 2 garden
./shop show 203
La lectura muestra cabecera y artículos vacíos. Una columna ausente es un error de esquema, no un código de recogida desconocido ni una compra vacía correcta.
Añade la nueva columna que admite null con un valor predeterminado explícito counter. ALTER TABLE cambia una definición; ADD COLUMN añade el campo. VARCHAR(16) almacena un código corto de recogida. NULL permite temporalmente un valor explícitamente desconocido durante esta fase de ampliación. DEFAULT 'counter' proporciona el valor de compatibilidad cuando un cliente antiguo omite la columna. También aparece en las filas preexistentes después de esta ampliación, por lo que no demuestra una elección histórica. El siguiente laboratorio independiente trata el historial aprobado antes de endurecer las reglas finales.
Guarda un archivo SQL completo. cat > expand.sql reemplaza este único archivo. El marcador de here-document entre comillas 'SQL' hace que el intérprete copie las líneas literalmente hasta el SQL final independiente. Un punto y coma termina cada instrucción SQL:
cat > expand.sql <<'SQL'
ALTER TABLE orders ADD COLUMN pickup_code VARCHAR(16) NULL DEFAULT 'counter';
SQL
apply ejecuta el archivo guardado sin cambios en una conexión nativa de MySQL por lotes con el rol de migración del curso. No deduce, completa datos históricos ni repara SQL ausente:
./shop apply expand.sql
./db -e "SHOW COLUMNS FROM orders;"
./db se conecta a la base de datos privada de este curso; -e ejecuta el SQL siguiente entre comillas y sale. Las comillas dobles mantienen los espacios y el punto y coma dentro de un único argumento del intérprete. Lee el tipo, la admisión de null y el valor predeterminado de la columna de recogida: varchar(16), YES, counter. Los demás campos originales siguen presentes.
Usa de nuevo el cliente antiguo y vuelve a intentar el pedido nuevo antes rechazado:
./shop old 202 Omar 1800 BAG 1
./shop new 203 Pia 1900 CARD 2 garden
./shop show 201
./shop show 202
./shop show 203
./shop status
Los pedidos 201 y 202 contienen el valor predeterminado realmente almacenado counter; 203 contiene garden. Se conservan todas las cabeceras y filas reales de artículos. Los tres pedidos originales muestran ahora counter como valor predeterminado de ampliación; no afirmes que todos los pedidos históricos se recogieron allí. La tabla preparada de correspondencias aprobadas permanece intacta.
Ante un error habitual de escritura de ./shopp, ejecuta ls y usa ./shop con el nombre correcto. Si SQL informa de un error de sintaxis, inspecciona cat expand.sql, corrige la instrucción guardada completa y aplícala solo si la columna sigue ausente. El error 1060 en una ampliación repetida significa que la columna ya existe; inspecciona SHOW COLUMNS en lugar de eliminarla o reiniciar la base de datos. Repetir un pedido de cliente realizado con éxito produce un error de ID duplicado: usa show para el pedido existente en lugar de inventar otro ID. Conserva los pedidos permitidos indicados y los datos originales.
Observar lo que una reversión no puede deshacer
En este paso, observarás un límite nativo de ALTER sobre una tabla de demostración separada, conservando intacto el sistema de pedidos.
Continúa en Terminal, en /home/labex/project/pickup-desk. ddl_demo es una tabla didáctica de una fila explícitamente desechable, separada de todos los pedidos. Su nota inicial es original:
./db -e "SELECT * FROM ddl_demo;"
Una transacción agrupa cambios de datos hasta COMMIT o ROLLBACK. START TRANSACTION inicia una; UPDATE cambia la fila seleccionada; ROLLBACK normalmente descarta sus cambios de datos sin confirmar. El DDL de MySQL (lenguaje de definición de datos), incluido ALTER TABLE, tiene un límite de commit implícito. ALTER confirma el trabajo anterior antes de cambiar la definición y un ROLLBACK posterior del usuario no lo deshace. La recuperación atómica de DDL no es lo mismo que permitir al usuario revertir DDL.
El archivo siguiente cambia deliberadamente solo esta nota de demostración antes de añadir una columna entera extra que admite null. Después solicita ROLLBACK. Antes de ejecutarlo, predice si se conservarán la nota y la columna nueva:
cat > ddl-demo.sql <<'SQL'
START TRANSACTION;
UPDATE ddl_demo SET note='committed before ALTER' WHERE id=1;
ALTER TABLE ddl_demo ADD COLUMN extra INT NULL;
ROLLBACK;
SQL
./shop apply ddl-demo.sql
./db -e "SELECT * FROM ddl_demo;"
./db -e "SHOW COLUMNS FROM ddl_demo;"
La fila todavía tiene la nota committed before ALTER y extra es NULL. SHOW COLUMNS sigue enumerando extra. El UPDATE anterior de datos fue confirmado por ALTER y la definición nueva también se conserva. Que ROLLBACK terminara correctamente no los deshizo. Es comportamiento real del servidor, no un archivo de salida inventado.
Lee de nuevo los pedidos reales:
./shop show 101
./shop show 201
./shop show 203
Se conservan sus valores originales de cabecera, notas, artículos y códigos de recogida almacenados. Nunca realices esta demostración sobre una nota de pedido. Una migración real separa la asignación transaccional de datos históricos del DDL posterior que endurece las reglas y planifica en consecuencia su límite de mantenimiento y reparación; poner cada ALTER dentro de BEGIN no proporciona una reversión automática.
El archivo de demostración es un script de una sola ejecución desde la definición inicial indicada. Si lo ejecutas dos veces por accidente, extra ya existe. Inspecciona la definición y la fila reales de demostración; no elimines la tabla para que una segunda ejecución parezca nueva. Restaura un archivo mal escrito copiando su bloque completo antes de la primera aplicación correcta. Esta unidad termina con una ampliación compatible y una observación veraz de DDL, no con una afirmación de despliegue bajo tráfico continuo de producción.
Resumen
Entregaste una ampliación compatible de la tabla de pedidos, observaste escrituras reales de los clientes antiguo y nuevo, y conservaste los detalles originales de los pedidos. Un experimento nativo aislado mostró por qué un ROLLBACK correcto no puede deshacer ALTER ni el cambio de datos anterior ya confirmado. Las elecciones históricas de recogida aún requieren la correspondencia aprobada que se enseña a continuación.
