Explain schema changes as a deployment step, not a run-time operation
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 80/100
- Type d'issue
- Documentation
- Clarté
- Clairement spécifiée
- Activité
- Active
- Domaine
- documentation
Piste de recherche
Commencez par how-to/deploy-production.md et examinez l’explication existante de create_tables=False. Ajoutez une page ou une section expliquant les modifications de schéma comme une étape de déploiement contrôlée, y compris le contenu de Lookup, allow_ddl, les identifiants de connexion distincts à la base de données et ce qui reste inchangé pour l’utilisation interactive. Le travail est terminé lorsque le guide couvre les points indiqués et est prêt à être livré avec le paramètre.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Jupyter Notebook
- Étoiles
- 7
- Forks
- 12
- Merge moyen
- 8 j 12 h
- PR mergées (30 j)
- 3
Préparer son environnement
- Fournit un Dockerfile ou un fichier Docker Compose
- Aucun modèle de pull request
- Aucun guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de datajoint/datajoint-docs
-
documentation
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
datajoint/datajoint-docs#301 · 1 commentaire ·
-
Difficulté 3/5 Une demi-journée Accessibilité débutants 55/100
datajoint/datajoint-docs#300 ·
-
Difficulté 3/5 Une demi-journée Accessibilité débutants 52/100
datajoint/datajoint-docs#299 · 1 commentaire ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
datajoint/datajoint-docs#298 ·
-
documentation
Difficulté 3/5 1-2 jours Accessibilité débutants 45/100
datajoint/datajoint-docs#292 ·
Toutes les issues de datajoint/datajoint-docs
Issues similaires
-
area/docs
Difficulté 1/5 Moins d'une heure Accessibilité débutants 83/100
Clodmony/starship-coop#72 ·
Les mainteneurs répondent en général sous 1 jour
-
documentation needs-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
nearform/ag-grid-url-sync#315 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
DigitecGalaxus/next-yak#727 · 1 réaction ·
-
documentation enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
-
good first issue priority:low type:docs
Difficulté 1/5 1-3 heures Accessibilité débutants 95/100
crazy-goat/rabbit-stream#969 ·
Les mainteneurs répondent en général sous 1 jour