i ask myself if there is a clean way/ procedure to ask Django to delete a single app. There are Topics with the same Question but they referencing to older Versions or i missed it.
I am newbie i don´t want to mess around with the django db by simply delete the Setting.py App registration. Because I saw that in the Django DB, between all the model entries, there are also data records of migrations, sessions, data entries or how i would call it, django magic.
I am using Django 2.1.7 within VirtualEnv.
So Far my procedure.
Delete the 'my_old_app' App-Registration in settings.py / INSTALLED_APPS
Change all entries in views.py, urls.py that have a connection to my_old_app
Deleting the model data of my_old_app. (simply Migrate?)
Thanks, for every Information.
You could follow these steps to delete an app in a good way.
delete unnecessary model in `models.py` and `migrate`
delete your app name from `settings.py` in INSTALLED_APPS
delete all folder `__pycache__ `
delete all import link in `views.py`, `admin.py` end etc.
delete all link's in `urls.py` that are unnecessary
delete app's folder
You could make use of --dry-run as mentioned by #Red Cricket in comments
Related
I have an app which was misconceived, and I would now like to delete it completely. I cannot find anything in the Django documentation about the right "blessed" way to do this.
I tried commenting out its models and running makemigrations but this threw errors because its views.py could not import them. If I removed its views from urls.py and tried, then makemigrations did not recognise that anything had changed.
Is it as simple as removing it from installed_apps in settings.py, removing its code, and manually deleting its one small model table from the DB? Or will the fact that it had an admin.py mean that there are dangling references left somewhere?
I'm using Django 2.2 if it makes any differerence
From experience:
Remove any foreign key relations to this delete_app's models
Make the migrations for those removals and apply
Delete all the references to delete_app from other apps
Delete all the code in delete_app except migrations
Make the migrations for the deleted models and apply
After this I'm still left with delete_app's migrations and its entry in INSTALLED_APPS because other migrations from other apps still refer some dependency on delete_app's migrations. Haven't had time to check how I can remove it completely, or if there is a recommended way of doing this, but hope this helps.
I am writing a small package that extends the django app that is used by many of my colleagues locally. So right now they can simply add it via pip, and then they add this extension in INSTALLED_APPS in settings.py.
But the problem is that I can't add the new models to this extension (or at least I don't figure out yet how to do it correctly) because then the guys who would like to use my extension, have to sync their database or make migrations so their database contains the models needed for extension.
Is it possible (and right thing to do) to add new models to the current django project 'silently' as soon as the user adds the app to INSTALLED_APPS?
I'm fairly new to python and django, and trying to build a simple calendar based on django-scheduler package.
According to django-scheduler docs, a custom base class can be used to add additional fields, managers and such.
So, I used an abstract model to add a new field:
#myproject/customer_calendar/models.py
from django.db import models
from main.models import Customer
class CalendarAbstract(models.Model):
customer = models.OneToOneField(to=Customer, null=True, blank=True, related_name='calendar')
class Meta:
abstract = True
And added this to settings.py
SCHEDULER_BASE_CLASSES = {
'Calendar': ['customer_calendar.models.CalendarAbstract'],
}
Now, if I use makemigrations command, a new migration is created inside scheduler app (which is located in site-packages of the current virtual env), which doesn't allow me to keep track of migrations via VCS.
I've found a couple of solutions:
1) Keep the whole scheduler app inside my project. According to SO it' s considered a bad practice and third-party apps should always be retrieved via pip.
2) Use django setting to store all django-scheduler migrations inside my calendar app
MIGRATION_MODULES = {
'schedule': 'customer_calendar.migrations',
}
The second one looks good to me, but I don't know if it's considered to be a valid solution to this problem.
Is there any other ways to store third-party apps migrations?
The second one looks good to me, but I don't know if it's considered
to be a valid solution to this problem. Is there any other ways to
store third-party apps migrations?
As also stated in this answer, FeinCMS docs recommend the use of MIGRATION_MODULES to monitor the migrations of FeinCMS as a third-party app.
FeinCMS itself does not come with any migrations. It is recommended
that you add migrations for FeinCMS models yourself inside your
project.
...
Create a new folder named migrate in your app with an empty init.py inside.
Add the following configuration to your settings.py:
MIGRATION_MODULES = {
'page': 'yourapp.migrate.page',
'medialibrary': 'yourapp.migrate.medialibrary', }
You must not use migrations as folder name for the FeinCMS migrations,
otherwise Django will get confused.
I have a huge... challenge in front of me. For about a week or two I've been migrating 1.5.5 django project to 1.7.1. A huge jump, many deprecated variables, methods and so on.
In 1.5.5 there were some south migrations done but not everywhere, as it was not implemented from the beginning. So let's say there are no migrations, they have to be created.
Also there is a wish to add a cms to the already upgraded project, but with django-cms-3.0.7 I constantly encounter some issues with migrations, south existing etc.
Is there a CMS that I can use with this app that won't be bothered by migrations and django version?
All I want to edit is the static content (text, images, maybe adding videos) before user logon. No integration with models. Just some info pages.
Any suggestions?
A maybe oversimplified solution for this could be django-front. Create your static pages and add the fields you want to edit. You edit it with a wysiwyg editor. I use it for my terms of service/privacy policy.
You will probably be always bothered by migrations and django version when using an app that brings extra functionality, but the apps should not be hard to upgrade and normally they have a warning/walk through when an important change on their arquitecture/functionality has happened.
That being said, i don't think migrations change dramatically now. The change to include them in the django project was an important (and needed) one.
If you want something even more simple (and time resistant) just create a model for your pages and render it on your template:
class Content(models.Model):
html_content = models.TextField()
image_content = models.ImageField()
Register that model to your admin and that should do the trick. For simple applications this may be enough.
I'm not sure what I am doing wrong. But the uploaded file and it's related cache don't get deleted when the entry is deleted.
I have a photos model inline of a property model, with an FK from the photos model to the property model. I am using 'from sorl.thumbnail import ImageField' to replace the default Django models.ImageField.
In Django Admin, when I delete the entry of a photo, the entry is deleted but the files for that entry are not deleted. I am using Django's runserver for the development and I am not seeing any errors. From what I have read, these files should be removed if the entry is deleted, unless there is a reference to them yet. The only reference that I am seeing yet is in the thumbnail_kvstore table.
Anyone have any thoughts on what I am missing?
The delete_file method will only be called in Django < v1.2.5. The best way to delete sorl.thumbnail.ImageField files, thumbnails and key value store references (used by sorl thumbnail) is to use sorl.thumbnail.delete function: sorl.thumbnail.delete(self.photo)
The ImageField from sorl.thumbnail should be an extension of django's FileField
From the release notes of django 1.2.5:
In earlier Django versions, when a model instance containing a FileField was deleted, FileField took it upon itself to also delete the file from the backend storage. This opened the door to several potentially serious data-loss scenarios, including rolled-back transactions and fields on different models referencing the same file. In Django 1.2.5, FileField will never delete files from the backend storage. If you need cleanup of orphaned files, you'll need to handle it yourself (for instance, with a custom management command that can be run manually or scheduled to run periodically via e.g. cron).
I had the problem with django-filebrowser, and when you replaced the image with a new one, the cached files did not update. So in my case it wasn't an issue with sorl-thumbnail but rather with django-filebrowser. sorl would only re-draw the thumbnails when the path of the file changed. To fix this I set the filebrowser FILEBROWSER_OVERWRITE_EXISTING setting to False.
FILEBROWSER_OVERWRITE_EXISTING = False
This may help someone at least debug the issue if they are not using django-filebrowser. But in the case of django-filebrowser this is the way to go. Cheers.