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 <[email protected]> a écrit :
> Hi I agree with [email protected] 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 <[email protected]>
> 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 <
>> [email protected]> 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 [email protected].
>>> 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 [email protected].
>> 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 [email protected].
> 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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-users/CA%2BGQzJMFKK6ejB4vXvcM%3DTEnGWreRi6gwYw6ZQ3R4HBgGO4aZg%40mail.gmail.com.
