Implémenter un processus de modification quotidienne des champs de modèle
dans un projet Django peut être complexe, mais c'est faisable. Voici
quelques points à considérer pour garantir que le processus fonctionne
efficacement dans un environnement de production :
✅Planification des tâches:
Pour automatiser la suppression et l'ajout de champs à une heure précise
chaque jour, vous pouvez utiliser un planificateur de tâches comme
**Celery** avec Django. Celery vous permet de gérer les tâches périodiques
de manière efficace. Vous pouvez également utiliser **Django-cron** pour
exécuter des tâches planifiées.
✅Gestion des migrations
Chaque fois que vous modifiez un modèle Django, vous devez créer et
appliquer des migrations pour mettre à jour la base de données. Vous pouvez
automatiser ce processus en utilisant des scripts qui exécutent les
commandes `makemigrations` et `migrate` de Django.
### Exemple de script pour les migrations
Voici un script de ce que j'avais utilisé dans mon application des
migrations :
```python
import os
import django
from django.core.management import call_command
from datetime import datetime
# Configurer Django
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mon_projet.settings')
django.setup()
# Fonction pour mettre à jour les modèles
def update_models():
# Supprimer le champ B
call_command('makemigrations', 'mon_app', name='remove_field_b')
call_command('migrate', 'mon_app')
# Ajouter le nouveau champ E
call_command('makemigrations', 'mon_app', name='add_field_e')
call_command('migrate', 'mon_app')
# Planifier l'exécution quotidienne
if datetime.now().hour == 2: # Remplacez 2 par l'heure souhaitée
update_models()
```
Le mar. 4 févr. 2025, 06:03, Agar Joshua <joshuaaga...@gmail.com> a écrit :
> Hi I agree with alexei.ramo...@gmail.com renaming fields and doing
> migrations is definitely not the most optimal solution. I suggest you have
> generic names. Anything variable mostly ends up being a field on a table or
> a table, depending on your use case. I hope you figured that out though?
>
> On Wed, Jan 29, 2025 at 11:05 PM Alexei Ramotar <alexei.ramo...@gmail.com>
> wrote:
>
>> I'd just give the columns generic names and let react handle the names
>> you want to display which is probably based on dates or something cyclical.
>> Otherwise it seems like too much overhead in renaming fields and migration.
>>
>> On Wed, Jan 29, 2025, 2:56 PM 'Ryan Nowakowski' via Django users <
>> django-users@googlegroups.com> wrote:
>>
>>>
>>> On 1/27/25 7:41 AM, Mayank Prajapati wrote:
>>> > I am making a full stack project with JavaScript and react for front
>>> end , Postgre SQL for database and Django for backend and Django rest
>>> framework for APIs. So in models.py file there's one field which is to be
>>> removed and another field is to be added at the end. This process has to be
>>> done once daily at specific time. For example, assume there are five fields
>>> in my models i.e. A,B,C,D and E. At some specific time field B will be
>>> removed and new field E will be added after D, again same process will
>>> repeat next day field C will be removed and new field F will be added after
>>> E. I can implement this process through python file handling and "with"
>>> method.
>>> >
>>> > So my question is, should i implement this process in my Django
>>> project? Will this process work efficiently in production environment?
>>> >
>>>
>>> When you say "field" are these FileFields <
>>> https://docs.djangoproject.com/en/5.1/ref/models/fields/#filefield>?
>>> And when you say "removed" and "added", are you talking about actually
>>> removing the field from the model(via migrations <
>>> https://docs.djangoproject.com/en/5.1/topics/migrations/>) or setting
>>> that field to "None"(null) when you "remove" it?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users+unsubscr...@googlegroups.com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/django-users/B1F2C8F6-766A-4515-ADEC-C72D59866E71%40fattuba.com
>>> <https://groups.google.com/d/msgid/django-users/B1F2C8F6-766A-4515-ADEC-C72D59866E71%40fattuba.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/django-users/CACCvK-vi3ooiMfKAGpMYyme4c2jA1fxbvY3HD0tdBRn7oc%2Bx%2BQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-users/CACCvK-vi3ooiMfKAGpMYyme4c2jA1fxbvY3HD0tdBRn7oc%2Bx%2BQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/django-users/CALHJg5%2BPWQXN3Wxnse8LZu%3Dm-1wgZ3S-EpCUk5hajMKR%3DPq3OA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-users/CALHJg5%2BPWQXN3Wxnse8LZu%3Dm-1wgZ3S-EpCUk5hajMKR%3DPq3OA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/django-users/CA%2BGQzJMFKK6ejB4vXvcM%3DTEnGWreRi6gwYw6ZQ3R4HBgGO4aZg%40mail.gmail.com.
