Publicando e revisando mudanças
Última atualização: 16 de julho de 2026
Toda mudança no Schema passa por uma Migration antes de entrar em vigor. Isso te dá a chance de revisar exatamente o que está prestes a mudar — e que impacto isso terá — antes de aplicar.
Como funcionam as Migrations
Quando você edita o Schema — adiciona um campo, atualiza um Enum, muda uma restrição — o Backoffice deixa a mudança preparada como uma Migration pendente. Ela não entra em vigor até você revisar e aplicar.
Cada Migration inclui um resumo Changes, mostrando o que será adicionado, removido ou modificado, e uma avaliação de Impact, indicando se a mudança é retrocompatível e quantas linhas serão afetadas.
Essa separação entre editar e aplicar mantém o Schema seguro: você pode fazer várias edições, revisá-las juntas e aplicar só quando tiver confiança de que o resultado está certo.
Review migration
Quando há mudanças staged, o botão Review migration aparece no canto superior direito da visão Schema. Clique nele para abrir o diálogo da Migration.
O diálogo mostra duas seções.
Changes lista cada modificação que será aplicada — valores novos, valores removidos, campos adicionados, restrições atualizadas. Cada mudança aparece como uma linha de diff, para você ver exatamente o que está sendo acrescentado ou retirado.
Impact diz se a Migration é segura de aplicar. Um rótulo Backward compatible significa que as leituras e escritas existentes continuam funcionando sem nenhuma mudança do lado do cliente. A estimativa de rows affected informa quantos Records existentes serão tocados — útil para pegar mudanças inesperadamente amplas antes de aplicá-las.
Se a Migration parecer correta, clique em Apply migration. Se algo estiver errado, clique em Cancel e continue editando — as mudanças staged permanecem até você estar pronto.
Remover um valor de Enum que já é usado em Records existentes é uma mudança destrutiva. Revise com atenção a estimativa de rows affected antes de aplicar remoções.
Mudanças de Schema que pedem mais atenção
Nem toda mudança de Schema carrega o mesmo risco. Adicionar um campo novo, um valor de Enum novo ou uma Entity nova é sempre retrocompatível — os Records existentes não são afetados e a mudança pode ser aplicada sem receio.
Remoções e modificações exigem mais cuidado. Remover um valor de Enum, apertar uma restrição ou mudar o tipo de um campo pode afetar Records existentes ou quebrar consultas em uso. Antes de aplicar essas mudanças, confira a seção Impact no diálogo e revise a seção Used by no rodapé do painel do objeto — ela mostra quais outros objetos referenciam aquele que você está alterando.
Quanto mais central um objeto é no Schema, mais cuidadosamente as mudanças nele devem ser revisadas. Um Enum usado em uma dúzia de campos merece mais escrutínio do que um campo em uma Entity pouco usada.
History
A aba History na visão Schema é um registro completo de todas as Migrations que já foram para o ar — a mais recente primeiro.
Cada entrada mostra o número da versão, uma descrição do que mudou, quem aplicou e quando. Clique em Diff em qualquer entrada para abrir o detalhamento do que exatamente mudou naquela Migration — no mesmo formato do diálogo Review migration.
Use o History para confirmar que uma Migration foi aplicada corretamente, rastrear quando uma mudança específica entrou, ou entender como o Schema evoluiu ao longo do tempo. O registro pode ser filtrado por intervalo de tempo e exportado.
O que conferir antes de aplicar
O erro mais comum é aplicar uma Migration sem ler o diff. O diff é curto — leva segundos para ler e evita o tipo de erro que leva muito mais tempo para consertar depois.
Antes de clicar em Apply migration, verifique:
- a descrição da mudança corresponde ao que você pretendia
- a seção Impact mostra Backward compatible
- a estimativa de rows affected faz sentido para a mudança que você fez
Um número grande de linhas afetadas por algo que parecia uma edi ção pequena costuma ser sinal de que mudou mais coisa do que você esperava.
Remover um campo é reversível por um tempo
Quando uma Migration remove um campo, os dados dele não são apagados na hora. O PlayServ os mantém por uma janela de retenção (7 dias por padrão) antes de finalizar a remoção, então re-adicionar o mesmo campo dentro dessa janela restaura os dados em vez de começar vazio. É uma rede de segurança para o clássico "removi, mas na verdade ainda precisava disso".
A janela é um período de graça, não armazenamento permanente. Depois que ela expira, os dados do campo removido são finalizados e somem — re-adicionar o campo a partir daí te dá um campo vazio. Trate a retenção como tempo para desfazer um erro, não como uma forma de arquivar dados que você vai querer de volta mais tarde.
Próximos passos
- Schema Object Reference — definições de todos os conceitos de Schema
- Building a Game Schema — como criar e conectar objetos de Schema
- Working with Game Data — criando e editando Records