django south - column none does not exist - python

i am failing to migrate using south. the problem is this:
i created a model, then i did schemamigration app --auto, then migrate app, it was fine. then later on, i added another field to this model and then did again those two commands, but now it is saying, column 'None' doesnot exist. i think, it was because i had a foreignkey field and that didnot have default value, i added some empty string default value, then did the commands again, it said the same error, now i deleted the model and did schemamigration and migrate app, but it still keeps giving this error.
this is my model:
class User(models.Model):
registerdate = models.CharField(max_length=400,default='')
vorname = models.CharField(max_length=100,default='')
nachname = models.CharField(max_length=100,default='')
email = models.EmailField(max_length=100,default='')
strasse = models.CharField(max_length=100,default='')
hausnr = models.CharField(max_length=100,default='')
stadt = models.CharField(max_length=100,default='')
land = models.CharField(max_length=100,default='')
##for confirm mails - the hash
unique = models.CharField(max_length=400,default='')
kennwort = models.CharField(max_length=200,default='')
username = models.CharField(max_length=200,default='')
locations = models.CharField(max_length=10, default='')
can someone please help me?
thanks a lot

field_name = models.CharField(max_length=400, blank=True)

You will have to edit your migration file, or regenerate it with a valid default. Your assumption of the invalid default is correct.

Related

Cannot alter tables after Django migration in posgres DB

I really need to know why in the world we cannot change the column types after we do the migrations to Postgres DB.
I already created my models by python manage.py makemigrations then do migrate. Everything looks fine and tables are created on the postgres DB.
class test_API(models.Model):
IDnumber = models.IntegerField(null=False, blank=False)
State = models.CharField(max_length = 256, null = True)
Exlcludmethod = models.CharField(max_length=256, null=True)
class test_API_2(models.Model):
Idnumber = models.Foreignkey(test_API, max_length = 256, blank=False, null = False)
value = models.CharField(max_length=128, default="")
last_updated = models.DateTimeField(auto_now=True)
Lets say we want to make change to IDnumber column from Integerfield to Charfield.
class test_API(models.Model):
IDnumber = models.CharField(null=False, blank=False)
State = models.CharField(max_length = 256, null = True)
Exlcludmethod = models.CharField(max_length=256, null=True)
and run the python manage.py makemigrations again
return self.cursor.execute(sql)
psycopg2.errors.DuplicateTable: relation "test_API" already exists
How can we modify/change column types and do migrations. What is the proper way of doing this ?
Using
Django:Django==4.0.3
Python = 3.9.1
Posgresql = 2.9.3
Django migrations using RunPython to commit changes
django 1.7 migrate gets error "table already exists"
It seems like you want to drop the link to test_API in test_API_2. If you want to be able store 'abcd' type strings, and not try to keep anything from the relation previously created by the ForeignKey field, then I believe you need to do this in a two step process.
First step would be to remove (or comment) the IDNnumber field, make migrations, then add it back with a new type of field.
The IDNumber field was more than an integer field, it has an indexed relation to test_API, so you need to sever that first by removing the field, then create a new field with identical name.

Adding db_table to model added a last_login field

Background: I started a project with a custom User model. However, noob that I am, I was unaware of the AbstractBaseUser class. So I just wrote my own. The app has been deployed to prod and working fine. But now I want to switch to using AbstractBaseUser so I can take advantage of some of the built-in Django utilities (like the pre-made password resetting process). I had done this with a different app and it worked fine. But that one wasn't in prod while I made the change. Because this one is, I needed to keep the old user table while I made the changes with a copy of it. So my first step was to add db_table = test_users to my old user model, so as to keep the prod app running with an unchanged table. I ran the migration, and two unexpected things happened (I'm a noob, and that's why they were unexpected):
The old user table was renamed. I thought a new table would be created. No problem, I quickly copied the new table and named the copy with the old table's name so the prod app could still find its users
A column last_login was added. Why??
Here's my model, with the added db_table
class User(models.Model):
first_name = models.CharField(max_length=255)
last_name = models.CharField(max_length=255)
email = models.CharField(max_length=255)
password = models.CharField(max_length=255)
created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)
client_id = models.IntegerField(blank=True, null=True)
is_admin = models.BooleanField(default=False)
is_super = models.BooleanField(default=False)
is_active = models.BooleanField(default=True)
class Meta:
db_table = "test_users"
The big problem with this is that when I change to AbstractBaseUser and run the migration, I get an error. Looking at the migration file I see that this change creates a migration that all it tries to do is to add last_login to the table. So, of course, the error I get is "Duplicate column name 'last_login'"
So, my question is two-fold:
Why was that column added in the first migration?
If I just run migrate --fake and keep going, will it have unintended consequences? I thought this could be a good solution, given that the migration file shows nothing else is being done, and if the field already exists, then no harm done?
Maybe because you've changed the parent class django automatically change all the migrations that connected to your user class

django.db.utils.ProgrammingError: column "questions" is of type character varying[] but default expression is of type integer

This is my model:
class college(models.Model):
image = models.ImageField(upload_to='college_image/',default=None)
name = models.CharField(max_length=100)
email = models.CharField(max_length=100,unique=True)
password = models.CharField(max_length=500)
add_field = models.CharField(max_length=200)
city = models.CharField(max_length=200)
state = models.CharField(max_length=200)
zipcode = models.CharField(max_length=10)
phone = models.CharField(max_length=10, validators=[RegexValidator(r'^[789]\d{9}$')])
status = models.BooleanField(default = True)
last_date = models.DateTimeField()
is_active = models.BooleanField(default = False)
reg_time = models.DateTimeField(auto_now_add=True,blank=True)
questions = ArrayField(models.CharField(max_length=500),blank=True)
def __str__(self):
return self.email
An error occurred when I added a questions field in the model and used command 'python manage.py migrate', and the following hint was shown:
HINT: You will need to rewrite or cast the expression
What does it mean? What should I do?
I know this is an old question but hopefully this answer can help somebody else. I fixed this same error by doing the following:
Add default list to the ArrayField. E.g.
answers = ArrayField(models.IntegerField(default=list))
Delete migration files in migrations folder except __init__.py
python manage.py make migrations
python manage.py migrate
So the issue was that in one of the migrations, the field was trying to be set to default 0 (programming error) but even after I fixed it in the code, the old migration was affected and thus it kept failing.

Django migrations

I am trying to build a blog on django. I have gone as far as creating models. Here they are:
from django.db import models
import uuid
class Users(models.Model):
username = models.CharField(max_length = 32, primary_key = True)
password = models.CharField(max_length = 32)
email = models.EmailField()
registration_date = models.DateTimeField(auto_now_add = True)
class Posts(models.Model):
author = models.ForeignKey("Users")
header = models.CharField(max_length=100)
body = models.TextField()
pub_date = models.DateTimeField(auto_now_add = True)
mod_date = models.DateTimeField(auto_now = True)
upvotes = models.PositiveIntegerField()
views = models.PositiveIntegerField()
post_id = models.AutoField(primary_key = True)
class Answers(models.Model):
body = models.TextField()
author = models.ForeignKey("Users")
pub_date = models.DateTimeField(auto_now_add = True)
mod_date = models.DateTimeField(auto_now = True)
post = models.ForeignKey("Posts")
answer_id = models.UUIDField(primary_key = True, default=uuid.uuid4)
After running python manage.py migrate I get the following:
You are trying to add a non-nullable field 'post_id' to posts without
a default; we can't do that (the database need mething to populate existing
rows).
Please select a fix:
1) Provide a one-off default now (will be set on all existing rows)
2) Quit, and let me add a default in models.py
Even if I press 1 and try to set a random one-off value, it migrates successfully but later on the website crashes with "no such table: blog_posts". But I think it should work without such workarounds as setting the default value manually anyway.
I tried playing with primary keys for Posts and Answers. I tried completely removing them so that django automatically sets them itself and tried changing it from AutoField to UUIDField and vice versa but it didn't help. What am I doing wrong?
You're seeing this error message because django is trying to build a consistent history of migrations, and it complains that if there was a database that held data with your old migrations, and you'd try to add a non-nullable field, it wouldn't know what to do.
Migrations are supposed to be put into version control and used across different development/production environments. If you add a field that must not be null, existing data of other environments (for example a production database that held models that did not have the field post_id) then django will warn you about this, with the error message that you got, and offer two solutions:
This field should always be prepoulated with a default value( you have to modify the models.py)
This is a one time migration and you supply a one-off value, for example "LEGACY" to mark pre-migration data.
If you're not in production and there is no valuable data on your development server, an easy way to fix this error message is just to delete the existing migration files and run python manage.py makemigrations && python manage.py migrate again.

Django is ignoring a field item for a Model with a fresh DB

I've completely wiped all my database tables in order to add a new field to a model since wiping SQL tables clean is the fastest way to do so without going the 'south' route when the SQL data only contains dummy data for testing purposes.
So here's my Model:
class Student(models.Model):
uid = models.ForeignKey(User)
title = models.CharField(max_length=250, help_text='The student name.')
resume = models.FileField(upload_to=get_upload_resume_name)
location = models.ForeignKey(Location)
country = models.ForeignKey(Country)
prim_interest = models.CharField(max_length=250, help_text='Maximum 250 characters.')
sec_interest = models.CharField(max_length=250, help_text='Maximum 250 characters.')
cellphone = models.IntegerField(default=0)
email_verified = models.BooleanField(default=False)
thumbnail = models.FileField(upload_to=get_upload_file_name)
def __unicode__(self):
return self.title
and the last field that I've added called 'thumbnail' is not being created by Django when I call syncdb right after deleting all my tables.
My method of completely wiping the tables has always worked no matter what drastic changes are applied to models.py and suddenly this is not the case for this instance. I could show you more code snippets but I have no clue where else in the Django project has a direct effect on generating models.
What could be causing syncdb to be refusing to write this new field 'thumbnail' to the Student table in the DB?
Could be That south is interfering. You habe no migrations waiting. If I remember well syncdb dos not create tables That south is scheduled to create.
Why not make a south migrate after your syncdb?

Categories

Resources