While refactoring an app, I've started removing a config file and replacing it with a new model, Foo in this example. Because of this, another model, Bar in this example, needs to change from having a CharField that was for the config file, to a ForeignKey that is for the new model.
Say I have
class Foo(models.Model):
name = models.CharField(primary_key=True, max_length=100)
class Bar(models.Model):
name_of_foo = models.CharField(max_length=100)
and I want to change name_of_foo to instead be a ForeignKey...
class Bar(models.Model):
foo = models.ForeignKey(Foo, on_delete=models.CASCADE, default=???)
I would like the default to be based on what name_of_foo was. If name_of_foo was "abc", I would like it to do something akin to default=Foo.objects.get("abc").
Is there a way to fill in the ??? such that this works nicely? If not, what steps can I take to arrive here, so that the existing data is converted?
I'm not sure if it is possible to achieve what you want using the default field but I'll leave it to someone else with more knowledge than me to answer that.
Assuming that a Foo object exists for each Bar object where foo.name = bar.name_of_foo you should be able to add a foreign key to Bar that links to the Foo object with the following steps.
Add foreign key field with null=True
class Bar(models.Model):
name_of_foo = models.CharField(max_length=100)
foo = models.ForeignKey(Foo, on_delete=models.CASCADE, null=True)
run makemigrations and migrate commands
Open the django shell
python manage.py shell
run the following code to update the foreign key of each Bar object (making changes where necessary)
from <app_name>.models import Foo, Bar
for foo in Foo.objects.all():
bar = Bar.objects.get(name_of_foo=foo.name)
bar.foo = foo
bar.save()
remove name_of_foo field
class Bar(models.Model):
foo = models.ForeignKey(Foo, on_delete=models.CASCADE, null=True)
run makemigrations and migrate commands
Related
I want to create an entry in this Something model in python manage.py shell using this
Someting.objects.create(discussion_title="General", user_username="admin", content="Hello")
models example
class Discussion(models.Model):
title = models.CharField(max_length=255, unique=True, blank=False,)
users = models.ManyToManyField(User, blank=True, )
class Something(models.Model):
user = models.ForeignKey(User,
on_delete=models.CASCADE)
discussion = models.ForeignKey(Discussion, on_delete=models.CASCADE)
timestamp = models.DateTimeField(auto_now_add=True)
content = models.TextField(unique=False, blank=False)
I am getting this error
TypeError: Something() got an unexpected keyword argument 'discussion_title'
First, you have to use double under bar __ to use django's model relation expression.
Someting.objects.get(discussion__title="General", user__username="admin", content="Hello")
Second, you can't use double under bar relation expression when create an object.
if you want to create an object in relation, you have to create in step by step. follow #Nicolas Appriou 's answer
Your Something model does not have a discussion_title field. You need to create a Discussion instance for this.
This model does not have a user_username model either.
discussion = Discussion.objects.create(title="Foobar")
discussion.users.add(User.objects.create(username="Ham")
Something.objects.create(
discussion=discussion,
)
Is is possible to protect a model in a reverse relationship. For instance in the models below:-
class Foo(models.Model):
foo_field1 = models.CharField(max_length=56, unique=True)
class Bar(models.Model):
bar_field1 = models.ForeignKey(Foo, on_delete=models.PROTECT, blank=True)
bar_field2 = models.CharField(max_length=56, unique=True)
If an attempt is made to delete an instance of Foo, it wont be deleted as the on_delete attribute on Bar is set to models.PROTECT. So, is it possible to extend that protection both ways? That is, if an attempt is made to delete an instance of Bar, so can it be protected just like Foo, can someone suggest a solution?.
I don't have a full solution for you, but I would suggest looking into using a Django Signal, specifilly pre-delete. You would in that signal check if bar_field_1 in instance of Bar is null and abort the deletion if it is not null.
Model
class SlackPermission(models.Model):
#fields
class GithubPermission(models.Model):
#fields
class Employee(models.Model):
#fields
slack_permission = models.OneToOneField(SlackPermission, on_delete=models.CASCADE, related_name='Slack',default=SlackPermission.objects.get(pk=1))
github_permission = models.OneToOneField(GithubPermission, on_delete=models.CASCADE, related_name='Github',default=GithubPermission.objects.get(pk=1))
Error:
ValueError: Cannot serialize: <GithubPermission: GithubPermission object (1)>
There are some values Django cannot serialize into migration files.
I am creating API just to create Employee. Where there is not option of giving slackpermissions and githubpermissions. How do I give default value in there?
The problem is that the default is calculated immediately, and for migrations, it can not really serialize that.
That bing said, it is not very useful to do this anyway. You can just pass the primary key as default value. This is specified in the documentation on the default=… parameter [Django-doc]:
For fields like ForeignKey that map to model instances, defaults should be the value of the field they reference (pk unless to_field is set) instead of model instances.
So we can write this as:
class Employee(models.Model):
full_name = models.CharField(max_length=100)
first_name = models.CharField(max_length=100)
last_name = models.CharField(max_length=100)
slack_permission = models.OneToOneField(
SlackPermission,
on_delete=models.CASCADE,
related_name='Slack',
default=1
)
github_permission = models.OneToOneField(
GithubPermission,
on_delete=models.CASCADE,
related_name='Github',
default=1
)
Note that you should ensure that there exists an object with that primary key. Therefore it might not be ideal to do that.
The issue here is that you are attempting to set a field value to an object instance. So your default value should be just 1 if you are certain of the pk.
Also, I am not sure the advantage of creating two separate models for these permission values. Seems like they can just be fields in your employee model. Seems like these permissions share identical fields as well which will allow you to flatten them a bit.
I have two models, with ManyToMany relationships:
App1:
class Foo:
fld = models.CharField(null=True, blank=True)
App2:
class Bar:
foos = models.ManyToManyField(Foo, blank=True)
Now, on the admin view of Bar, I'd like to present foos. I cannot simply list foos as a ManyToMany field, I get an error message.
So I try to do:
class BarFooInline(admin.TabularInline):
model = Bar_foos
class BarAdmin(admin.ModelAdmin):
model = Bar
inlines = [BarFooInline, ]
admin.site.register(Bar, BarAdmin)
I got the name Bar_foos by look into the Meta of Bar. Bar.foos.through yields that as a proper models.Bar_foos. But since I didn't explicitly name the through, it's not really in the models.py, so I cannot import that. What should I do?
I don't want to create a through now, because I already have a whole bunch of association information in the table, and I have a feeling that wouldn't be magically data migrated into the newly named association entity's table (https://mounirmesselmeni.github.io/2013/07/28/migrate-django-manytomany-field-to-manytomany-through-with-south/).
Also, I cannot move the ManyToMany field from App2 to App1.
class BarFooInline(admin.TabularInine):
models = Bar.foos.through
class BarAdmin(admin.ModelAdmin):
model = Bar
inlines = [BarFooInline]
exclude = ['foos']
Working with many-to-many models.
I need to change the type of a field in one of my Django models from CharField to ForeignKey. The fields are already populated with data, so I was wondering what is the best or right way to do this. Can I just update the field type and migrate, or are there any possible 'gotchas' to be aware of? N.B.: I just use vanilla Django management operations (makemigrations and migrate), not South.
This is likely a case where you want to do a multi-stage migration. My recommendation for this would look something like the following.
First off, let's assume this is your initial model, inside an application called discography:
from django.db import models
class Album(models.Model):
name = models.CharField(max_length=255)
artist = models.CharField(max_length=255)
Now, you realize that you want to use a ForeignKey for the artist instead. Well, as mentioned, this is not just a simple process for this. It has to be done in several steps.
Step 1, add a new field for the ForeignKey, making sure to mark it as null:
from django.db import models
class Album(models.Model):
name = models.CharField(max_length=255)
artist = models.CharField(max_length=255)
artist_link = models.ForeignKey('Artist', null=True)
class Artist(models.Model):
name = models.CharField(max_length=255)
...and create a migration for this change.
./manage.py makemigrations discography
Step 2, populate your new field. In order to do this, you have to create an empty migration.
./manage.py makemigrations --empty --name transfer_artists discography
Once you have this empty migration, you want to add a single RunPython operation to it in order to link your records. In this case, it could look something like this:
def link_artists(apps, schema_editor):
Album = apps.get_model('discography', 'Album')
Artist = apps.get_model('discography', 'Artist')
for album in Album.objects.all():
artist, created = Artist.objects.get_or_create(name=album.artist)
album.artist_link = artist
album.save()
Now that your data is transferred to the new field, you could actually be done and leave everything as is, using the new field for everything. Or, if you want to do a bit of cleanup, you want to create two more migrations.
For your first migration, you will want to delete your original field, artist. For your second migration, rename the new field artist_link to artist.
This is done in multiple steps to ensure that Django recognizes the operations properly. You could create a migration manually to handle this, but I will leave that to you to figure out.
Adding on top of Joey's answer, detailed steps for Django 2.2.11.
Here are the models from my use case, that consists of a Company and Employee model. We have to convert designation to a foreign key field. The app name is called core
class Company(CommonFields):
name = models.CharField(max_length=255, blank=True, null=True
class Employee(CommonFields):
company = models.ForeignKey("Company", on_delete=models.CASCADE, blank=True, null=True)
designation = models.CharField(max_length=100, blank=True, null=True)
Step 1
Create a foreign key designation_link in Employee and mark it as null=True
class Designation(CommonFields):
name = models.CharField(max_length=255)
company = models.ForeignKey("Company", on_delete=models.CASCADE, blank=True, null=True)
class Employee(CommonFields):
company = models.ForeignKey("Company", on_delete=models.CASCADE, blank=True, null=True)
designation = models.CharField(max_length=100, blank=True, null=True)
designation_link = models.ForeignKey("Designation", on_delete=models.CASCADE, blank=True, null=True)
Step 2
Create empty migration. Using the command:
python app_code/manage.py makemigrations --empty --name transfer_designations core
This will create a following file in migrations directory.
# Generated by Django 2.2.11 on 2020-04-02 05:56
from django.db import migrations
class Migration(migrations.Migration):
dependencies = [
('core', '0006_auto_20200402_1119'),
]
operations = [
]
Step 3
Populate the empty migration with a function that loops over all Employees, creates a Designation and links it to the Employee.
In my use case each Designation is also linked to a Company. Which means that Designation may contain two rows for "managers", one for company A, another for company B.
Final migration would look something like this:
# core/migrations/0007_transfer_designations.py
# Generated by Django 2.2.11 on 2020-04-02 05:56
from django.db import migrations
def link_designation(apps, schema_editor):
Employee = apps.get_model('core', 'Employee')
Designation = apps.get_model('core', 'Designation')
for emp in Employee.objects.all():
if(emp.designation is not None and emp.company is not None):
desig, created = Designation.objects.get_or_create(name=emp.designation, company=emp.company)
emp.designation_link = desig
emp.save()
class Migration(migrations.Migration):
dependencies = [
('core', '0006_auto_20200402_1119'),
]
operations = [
migrations.RunPython(link_designation),
]
Step 4
Finally run this migration using:
python app_code/manage.py migrate core 0007
That's a continuation of the great answer by Joey.
How to rename the new field to the original name?
If the field has data, it probably means that you are using it elsewhere in your project, therefore this solution will leave you with a field named differently, and you have to either refactor the project to use the new field or delete the old field and rename the new one.
Be aware that this process is not going to prevent you to refactor code. If you where using a CharField with CHOICES, you were accessing its content with get_filename_display(), for example.
If you try to delete the field to make a migration, for then renaming the other field and make another migration, you'll see Django complaining because you cannot delete a field that you are using in the project.
Just create an empty migration as Joey explained, and put this in operations:
operations = [
migrations.RemoveField(
model_name='app_name',
name='old_field_name',
),
migrations.RenameField(
model_name='app_name',
old_name='old_field_name_link',
new_name='old_field_name',
),
]
Then run migrate and you'll have the changes made in your database, but obviously not in your model, it's time now to delete the old field and to rename new ForeignKey field to the original name.
I don't think that doing this is particularly hacky, but still, only do this kind of things if you are fully understanding what are you messing with.