Explain schema changes as a deployment step, not a run-time operation
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 2/5
- Tempo estimado
- 1-3 horas
- Facilidade para iniciantes
- 80/100
- Tipo de issue
- Documentação
- Clareza
- Claramente especificada
- Status de atividade
- Ativa
- Domínio
- documentation
Direção de pesquisa
Comece por how-to/deploy-production.md e revise a explicação existente de create_tables=False. Adicione uma página ou seção que explique as alterações de esquema como uma etapa controlada da implantação, incluindo o conteúdo de Lookup, allow_ddl, logins separados do banco de dados e o que permanece inalterado para o uso interativo. O trabalho estará concluído quando o guia cobrir os pontos listados e estiver pronto para ser publicado com a configuração.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
The docs describe create_tables=False for production (how-to/deploy-production.md), but don't explain the principle behind it.
Proposal
Add an explanation page, or a section of the production guide, covering:
- The principle. A schema change (declaring a table, altering or dropping it, changing a Lookup table's contents) is part of deploying new code. It is applied once, in a controlled step, before processes start running the new code.
- Lookup contents count as schema. They change with the code, not at run time.
- Why it matters. Run-time declaration is convenient for interactive work, but in a shared database it means whichever process imports new code first changes the schema, unreviewed. A table and the code that fills it should change together, at a known moment.
- How to set it up. The
allow_ddlsetting (datajoint/datajoint-python#1649), separate database logins for deployment and for run time, and the deployment step that applies the changes. - What stays the same for interactive use. The defaults keep today's convenience.
This page should land in the same release as the setting.
- Linguagem predominante
- Jupyter Notebook
- Estrelas
- 7
- Forks
- 12
- Merge médio
- 8d 12h
- PRs com merge (30d)
- 3
Preparar o ambiente
- Inclui um Dockerfile ou arquivo Docker Compose
- Sem modelo de pull request
- Sem guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de datajoint/datajoint-docs
-
documentation
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
datajoint/datajoint-docs#301 · 1 comentário ·
-
Dificuldade 3/5 Meio dia Facilidade para iniciantes 55/100
datajoint/datajoint-docs#300 ·
-
Dificuldade 3/5 Meio dia Facilidade para iniciantes 52/100
datajoint/datajoint-docs#299 · 1 comentário ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 55/100
datajoint/datajoint-docs#298 ·
-
documentation
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
datajoint/datajoint-docs#292 ·
Todas as issues de datajoint/datajoint-docs
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
juandresrodca/AdminForge#54 ·
-
hermes-queue
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 72/100
chrisalunlloyd2-sudo/mindpalace#349 ·
Mantenedores costumam responder em até 1 dia
-
external
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
langchain-ai/docs#7524 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 66/100
Mantenedores costumam responder em até 1 dia
-
bugfix low-priority plugin:abstract plugin:leyline small-effort source:discussion
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 66/100
athola/claude-night-market#1132 ·