I have deleted one column from my model. Then I deleted database, migration files, venv direcotry, and pycache. But after executing makemigrations the old db schema is generating ( it still contains this column). What is the problem. How django knows about this column. It's no longer present in data model.
Django automatically creates a primary key column if you don't define one in your model. It is explained here:
By default, Django gives each model the following field:
id = models.AutoField(primary_key=True)
This is an auto-incrementing primary key.
If you’d like to specify a custom primary key, specify primary_key=True on one of your fields. If Django sees you’ve explicitly set Field.primary_key, it won’t add the automatic id column.
Each model requires exactly one field to have primary_key=True (either explicitly declared or automatically added).
Since you happened to declare it explicitly with the same defaults, you won't notice any difference.
you also need to run python manage.py migrate after makemigrations to commit the changes to the database, then everything should be fine
Related
I have created a model and migrated in Django, with a unique key constraint for one of the field. Now am trying to remove the unique constraint and generate another migration file with the new change, but it says "Nothing seems to have changed".
I tried with the command
python manage.py schemamigration --auto
PS: I am using OnetoOne relationship for the field.
Good question. A one to one relationship implies that one record is associated with another record uniquely. Even though the unique constraint is removed(for one to one field) in the code explicitly, it won't be reflected in your DB. So it won't create any migration file.
If you try the same thing for foreign constraint, it will work.
I find the django automigration file generation problematic and incomplete.
Actually I experienced another similar problem with django migration just yesterday.
How I solved it:
delete all migration files from the /migrations folder
do a fresh makemigrations
run python manage.py migrate --fake so django does not try to rebuild..
Hey presto! Working and models updated :D
I have seen several questions and answers on SO, most were three years old or older and I looked at the Django documentation (hoping I didn't miss it). I have to have a 9+ digit number for an id. Most responses were to do this at the database. I am guessing that means to create the model in Django and then go back to the database and change the id column Django created with a new starting/next value attribute on the column.
If not how can I create a database table from Django, Code First, that allows me to create a table with an id column that starts at 100000000? And, it be done with the stock model object methods in Django. I don't really want to do a special hack. If that is the case, I can go the database and fix the column. I was trying to adhere to the Code First ideas of Django (though I prefer database first, and am afraid using inspectdb will make a mess.)
Edit: I didn't want to use UUID. I believe BigAutoField is best.
You should be able to do this in two steps:
1 - Specify your primary key explicitly using primary_key=TRUE in your model definition. See the Django docs for more info. You can then specify BigAutoField or whatever other type you want for the primary key.
2A - If you're populating the database up front, just set pk: 100000000 in your fixture.
OR
2B - If you're not populating the database up front, use Django Model Migration Operations RunSQL as detailed here. For your SQL use ALTER TABLE tableName AUTO_INCREMENT=100000000.
I have a Django model called Message:
class Message(models.Model):
text = models.CharField(max_length=50)
sending_time = models.DateTimeField(auto_now_add=True)
I added sender = models.ForeignKey(User) to this model in my Django code. Next, I wanted to explore doing changes in the postgresql table manually, without invoking syncdb or south.
So I logged into psql and did the following:
ALTER TABLE message ADD COLUMN "sender" INTEGER DEFAULT 1;
ALTER TABLE message ADD CONSTRAINT fk_message_user FOREIGN KEY (sender) REFERENCES user(id);
With those two commands, I successfully added a new column with default value 1, containing a foreign key to Django's built-in User model.
After I had done that, I figured I had successfully approximated what Django does with syncdb or south. I ran my web app - everything looked good. But then as soon as I hit the first database transaction in my code, the following error resulted:
DatabaseError: current transaction is aborted, commands ignored until
end of transaction block
I'm unable to get it to work unless I delete the column I manually added (or rollback the transaction), but not otherwise. syncdb is an option, but let's exclude it for this question.
What did I miss when I manually provisioned that foreignkey field? Can someone walk me through the process? I'm assuming running a migration simply automates steps one could have done manually too. I need to understand the anatomy of that process, hence doing it by hand. That's what this question's about.
I am new to Django. I have completed the tutorial and am reading the documentation for more learning. As I try to add to my understanding, say, in new Managers or ModelForms I am curious as to what needs South (or even just scrapping it and rewriting the app).
update django database to reflect changes in existing models
The link above says basically that any column change it is necessary, while the link below is more of what I am asking. Can someone generalize when it is not needed (eg: Adding a new Form/ModelForm based on an existing Model? Adding a Manager?) If no changes are made to the columns of the database South is not then not necessary?
Does changing a django models related_name attribute require a south migration?
There are two types of south migrations: schema and data.
Data migrations are used to change data in the DB and not the schema of the DB.
The schema migrations are the ones you are interested in. They are used to keep track of changes to the DB schema and one should accompany any changes to your models that result in DB schema change (create table, drop table, drop column, change null constrain e.g.)
Some great insights might be found if you read two consecutive migrations for a django app.
In each of them you can find code that applies the migreation, code that reverts the migrations and a snapshot of the DB schema.
P.S. It is quite easy to check if south migration is needed for a particular change in your models. Just run a schemamigration for the modified django app and delete the newly created migration if such was created. As creating a south migration is different that running it, this is a great way to test and learn.
Keep in mind that south is a piece of software like any other and it does 'support' bugs.
Related_name attribute changes only affect your project and django uses it to make queries.
Changes like blank = True/False, null = True/False, symmetrical = True/False require database changes although symmetrical = True/False does not trigger update by south, but the setting definitely makes difference at field creation.
Column changes, like the link in your post shows, require updates in database and that's what south does very good.
I have a Django project that started as an import of a legacy database. Because of this, there is a model with a composite primary key. This worked as long as I used only the legacy data, but now I want to add new data and the form I created is telling me that I am trying to insert duplicate data, presumably because it is only looking at one of the fields as the primary key.
Now I want to change the model to use an autoincrement primary key, like one Django would automatically add. I tried removing the primary key attributes from the fields and putting them in unique_together in the Meta inner class. When I ran schemamigration with South, it wanted to add an id field as expected, but it asked for a default value.
How can I specify that South should assign unique keys in some way that is reasonable for an autoincrement field? (i.e. assign the sequence [1...n] to some arbitrary ordering of the records)
If this is impossible is there another way to accomplish the same thing, preferably using Django and South?
I solved the problem that required me to do this with a workaround:
I copied the data from the original table into a temporary table in SQL with INSERT INTO... SELECT.... I then deleted the original table and recreated it with the autoincrement field. Then I copied the data back into the new table, with the autoincrement values added automatically by the INSERT command. Finally I executed a fake run of the South migration to make South's tables consistent with the new schema.