Introdução
Uma pequena loja está adicionando pontos de retirada. Seu checkout antigo fornece ID do pedido, cliente, centavos inteiros e uma nota; um novo checkout também fornece um código de retirada. Os pedidos existentes e seus relacionamentos com os itens devem continuar utilizáveis. Um valor padrão mantém a compatibilidade quando uma coluna é omitida, mas não informa onde um cliente histórico realmente escolheu retirar um pedido.
Você entregará expand.sql e uma tabela real de pedidos expandida, usará os dois clientes preparados e observará o limite real entre transações de dados e DDL do MySQL. Os pré-requisitos são navegação básica no terminal e SELECT/WHERE, INSERT/UPDATE, colunas, chaves primárias e valores padrão do MySQL. Não é necessário desenvolver em Python nem criar uma aplicação. Esta unidade independente fornece seu próprio Oracle MySQL privado e Terminal; o serviço genérico de banco de dados não está relacionado.
Trabalhe apenas em /home/labex/project/pickup-desk. Você pode adicionar a coluna documentada de retirada a orders e atualizar/expandir apenas a tabela isolada ddl_demo para a demonstração. Preserve todos os IDs originais de pedidos, clientes, valores, notas, itens, pontos e tabelas de aprovação, além das ferramentas fornecidas. Apenas os três pedidos nomeados de prática abaixo podem ser adicionados. Esta é uma janela controlada de manutenção, não uma migração online, sem bloqueios ou sem indisponibilidade. A estimativa de tempo do autor inclui leitura e erros comuns; ela não foi cronometrada com iniciantes.
Expandir o esquema enquanto os dois clientes continuam funcionando
Nesta etapa, você criará um pedido normal pelo cliente legado, adicionará uma coluna compatível de retirada e consultará pedidos reais criados pelas duas versões do cliente.
Comece em Terminal, no prompt do shell. cd muda o diretório atual; o caminho absoluto funciona a partir de qualquer diretório inicial. ./shop executa um comando preparado nesse diretório. Estes são comandos do shell, não entradas em um prompt do MySQL:
cd /home/labex/project/pickup-desk
./shop status
./shop points
Os cabeçalhos originais são 101 / Sam / 2100, 102 / Sam / 3400 e 103 / Lee / 0, com suas próprias notas e itens. Os dois pedidos de Sam são identidades diferentes. Os valores são centavos inteiros, e zero é válido. status e show consultam valores realmente armazenados; nunca migram um registro nem substituem uma escolha de retirada.
O cliente legado preparado aceita old order_id customer total_cents sku quantity. Ele insere um cabeçalho usando nomes explícitos das colunas antigas e um item na mesma transação nativa. Uma chamada bem-sucedida confirma a transação; um erro SQL nativo interrompe o lote e fecha sua conexão, desfazendo alterações pendentes de dados. Crie o pedido comum permitido e consulte-o:
./shop old 201 Mina 1600 MUG 1
./shop show 201
Seu cabeçalho contém ID 201, Mina, 1600 e Created by legacy client; seu detalhe contém MUG, quantidade 1. O pickup_column: false retornado informa que esse campo não foi implantado. O novo cliente tem os mesmos argumentos seguidos de um código de retirada. O próximo comando deve falhar intencionalmente com o erro nativo 1054, coluna desconhecida pickup_code, e status de saída diferente de zero. Ele não deve deixar cabeçalho nem detalhe:
./shop new 203 Pia 1900 CARD 2 garden
./shop show 203
A consulta mostra cabeçalho/itens vazios. Uma coluna ausente é um erro de esquema, não um código de retirada desconhecido nem um checkout vazio bem-sucedido.
Adicione a nova coluna que permite NULL com um padrão explícito de counter. ALTER TABLE altera uma definição; ADD COLUMN adiciona o campo. VARCHAR(16) armazena um código curto de retirada. NULL permite temporariamente um valor explicitamente desconhecido durante esta fase de expansão. DEFAULT 'counter' fornece o valor de compatibilidade quando um cliente antigo omite a coluna. Ele também aparece em linhas preexistentes após esta expansão, portanto não comprova uma escolha histórica. O próximo lab independente trata o histórico aprovado antes de tornar as regras finais mais restritivas.
Salve um arquivo SQL completo. cat > expand.sql substitui apenas esse arquivo. O marcador 'SQL' do here-document entre aspas faz o shell copiar as linhas literalmente até o SQL final sozinho na linha. Um ponto e vírgula encerra cada instrução SQL:
cat > expand.sql <<'SQL'
ALTER TABLE orders ADD COLUMN pickup_code VARCHAR(16) NULL DEFAULT 'counter';
SQL
apply executa o arquivo salvo sem alterações em uma conexão nativa de lote MySQL com o papel de migração do curso. Ele não deduz, não preenche dados históricos nem corrige SQL ausente:
./shop apply expand.sql
./db -e "SHOW COLUMNS FROM orders;"
./db se conecta ao banco de dados privado deste curso; -e executa o SQL seguinte entre aspas e sai. As aspas duplas mantêm espaços e o ponto e vírgula dentro de um argumento do shell. Observe o tipo, a permissão de NULL e o padrão da coluna de retirada: varchar(16), YES, counter. Os outros campos originais permanecem presentes.
Use novamente o cliente legado e repita o novo pedido anteriormente rejeitado:
./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
Os pedidos 201 e 202 contêm o padrão counter realmente armazenado; 203 contém garden. Todos os cabeçalhos e linhas reais de itens permanecem. Os três pedidos originais agora exibem counter como padrão da expansão; não afirme que todos os pedidos históricos foram retirados ali. O mapeamento preparado de aprovação permanece intocado.
Para um erro comum de digitação ./shopp, execute ls e use ./shop com o nome correto. Se o SQL informar um erro de sintaxe, inspecione cat expand.sql, corrija a instrução completa salva e aplique-a apenas se a coluna ainda estiver ausente. O erro 1060 em uma expansão repetida significa que a coluna já existe; inspecione SHOW COLUMNS em vez de removê-la ou reinicializar o banco de dados. Repetir um pedido de cliente bem-sucedido produz um erro de ID duplicado: use show para o pedido existente, em vez de inventar outro ID. Mantenha os pedidos permitidos nomeados e os dados originais.
Observar o que um rollback não consegue desfazer
Nesta etapa, você observará um limite nativo de ALTER em uma tabela separada de demonstração, mantendo o sistema de pedidos intacto.
Continue em Terminal, em /home/labex/project/pickup-desk. ddl_demo é uma tabela didática explicitamente descartável de uma linha, separada de todos os pedidos. Sua nota inicial é original:
./db -e "SELECT * FROM ddl_demo;"
Uma transação agrupa alterações de dados até COMMIT ou ROLLBACK. START TRANSACTION inicia uma; UPDATE altera a linha selecionada; ROLLBACK normalmente descarta suas alterações de dados não confirmadas. DDL do MySQL (linguagem de definição de dados), incluindo ALTER TABLE, tem um limite de commit implícito. ALTER confirma o trabalho anterior antes de alterar a definição e não é desfeito por um ROLLBACK posterior do usuário. Recuperação de DDL atômico não é o mesmo que tornar o DDL do usuário reversível por rollback.
O arquivo a seguir altera deliberadamente apenas esta nota de demonstração antes de adicionar uma coluna inteira extra que permite NULL. Depois, solicita ROLLBACK. Antes de executá-lo, preveja se a nota e a nova coluna permanecerão:
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;"
A linha ainda tem a nota committed before ALTER, e extra é NULL. SHOW COLUMNS ainda lista extra. O UPDATE anterior dos dados foi confirmado por ALTER, e a nova definição também permanece. O retorno bem-sucedido de ROLLBACK não os desfez. Este é o comportamento real do servidor, não um arquivo fabricado de saída.
Consulte os pedidos reais novamente:
./shop show 101
./shop show 201
./shop show 203
Seus valores originais de cabeçalho, notas, itens e códigos armazenados de retirada permanecem. Nunca faça esta demonstração em uma nota de pedido. Uma migração real separa um preenchimento histórico transacional de dados do DDL posterior de restrições e planeja seu limite de manutenção/reparo de acordo; colocar todo ALTER dentro de BEGIN não fornece rollback automático.
O arquivo de demonstração é um script executado uma única vez a partir da definição inicial declarada. Se executá-lo acidentalmente duas vezes, extra já existe. Inspecione a definição e a linha reais da demonstração; não a remova para fazer uma segunda execução parecer nova. Restaure um arquivo digitado incorretamente copiando seu bloco completo antes da primeira aplicação bem-sucedida. Esta unidade termina com uma expansão compatível e uma observação honesta de DDL, não com uma afirmação de implantação sob tráfego contínuo de produção.
Resumo
Você entregou uma expansão compatível da tabela de pedidos, observou escritas reais dos clientes antigo/novo e preservou os detalhes originais dos pedidos. Um experimento nativo isolado mostrou por que um ROLLBACK bem-sucedido não consegue desfazer ALTER nem a alteração de dados confirmada que o precedeu. Escolhas históricas de retirada ainda exigem o mapeamento aprovado ensinado a seguir.
