I see some issues in my database while updating my model in Django. it only shows 12 fields!
when I added one more field to it and then run makemigrations command, it does not show any changes.
I'm using MySQL database init. is there anything in the Django model like we can only define some fields or we can define as much as we need?
You should be a able to create as my fields as you want. I recommend deleting all files in your migrations folder, except __int__.py file and try python manage.py makemigrations and python manage.py migrate again.
If this doesn't work, also delete the db.sqlite3 file. This usually works for me!
Related
I'm creating my site with Django and MySQL (all are the latest versions), but my database plan was changed. now I want to edit my MySQL database. the project is still testing in fact I don't need any data from the database. I'm new to python, and Django with MySQL. please help with this.
thank you
Delete all files in migrations folder except __init__.py
Delete database file db.sqlite3
Execute python manage.py makemigrations
Execute python manage.py migrate
Now you should have new database file created and initial migrations applied for each application.
You can follow next steps if you don't need any data in your DB
Delete all migrations files (Save them just in case)
Create new database
Set new database in settings.py
makemigrations and migrate on new database
I created a fixture with this command:
python manage.py dumpdata --natural-primary --natural-foreign -e admin -e contenttypes -e auth.Permission --format=json --indent=2 --all > gc_core/fixtures/initial_data.json
Then I tried to test it on my other machine. So I deleted my database and run migrations there:
./manage.py migrate
Then I tried to populate my database with that fixture using loaddata:
./manage.py loaddata gc_core/fixtures/initial_data.json
Then Django raises this error:
django.db.utils.OperationalError: Problem installing fixtures: no such column: REFERRED.id
I have no idea what this means. Should I have a column somewhere named REFERRED.id?
There is no such column in my fixture nor in the database and I didn't defined such model in any of my apps.
So what is REFERRED.id and how do I fix it?
I'm using Django 1.10, Python 3.5.2, SQLite. The fixture I'm trying to load is in JSON format.
Thank you in advance.
I stumbled upon this question when I encountered the same issue.
Here is a possible answer that is likely just a theory but I will explain why.
Django is having trouble loading relationships with primary keys that are not auto indexes on SQLite databases.
I am encountering this issue because the test database strategy we employ is by using an SQLite database instead of the production like Postgres database. I have been breaking my head over the exact same error all day. When I switched to Postgres for the test database as well, it ended up not being an issue. There might be a bigger problem at large here. Hopefully someone else can provide a more clear answer.
I am using the same version of Django and Python 2.7
If possible, could you try moving the data into a Postgres equivalent and load it. If that does work, it means your data is not wrong, and the relationship SQLite and Django is having issues.
Background info:
I am quite beginner with django, better equipped with python and quite beginner in mysql (and thus mariaDB) as well.
I work in Windows 7 environment with the following versions:
django 1.9.1
mariaDB 10.0.20
Python 3.4.4
mysql-connector\Python 2.1.3 for Python 3.4
Goal:
I am trying to build mariaDB database and web based user interface for it with django. I have built the database beforehand in mysql and am now trying to create the django project using this database as legacy database.
Problem:
I have retrieved the models to my django project as follows:
python manage.py inspectdb > models.py
and it worked fine. Checked the models.py, as well, and they seemed as they should.
Now, if I try to migrate to create the tables based on django to my legacy db as follows:
python manage.py migrate
I keep getting plenty of nested errors last one being:
django.db.migrations.exceptions.MigrationsSchemaMissing: Unable to create the django_migrations table (Table 'mydb'.'django_migrations' already exists. Please DISCARD the tablespace before IMPORT.)
I figured the table was left in my database folder from previous attempt, but removing it does not help. Even if I check from the database command prompt that the only tables left are native to my database, this same error message pops up still. At some point I wondered if there is some issue with the connector I am using as it is not the recommended one (mysqlclient).
Somewhere, I found that the migration would not even be required. This would obviously save me, but I have no idea, if that is a solution I can go for. Ideally the database would be managed later online and users with admin accounts could add entries there. Otherwise, however the database should be just returning the data.
EDIT: Fixed the error message the python manage.py inspectdb > models.py line
EDIT 29.1.
Running the migration as:
python manage.py migrate --fake
results in the same error.
The issue persists even after removing the django project and starting it fresh.
EDIT v2 29.1.
There is only one of the required table files for the django_migrations table within the database folder. There should be django_migrations.ibd AND django_migrations.frm. However, after running the migration, there is only one file: django_migrations.ibd.
There was something similar going on here, with different file
mysqldump problems with restore error: 'Please DISCARD the tablespace before IMPORT'. It is well explained in the chosen answer.
I think this is related to my issue, but cannot figure out what could help and what to do with this.
EDIT v3 29.1.
And finally I noticed the file giving the django error. It is django's migration recorder at C:\Python34\lib\site-packages\django\db\migrations\recorder.py on line 59.
def ensure_schema(self):
"""
Ensures the table exists and has the correct schema.
"""
# If the table's there, that's fine - we've never changed its schema
# in the codebase.
if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
return
# Make the table
try:
with self.connection.schema_editor() as editor:
editor.create_model(self.Migration)
except DatabaseError as exc:
raise MigrationSchemaMissing("Unable to create the django_migrations table (%s)" % exc)
Where the last line raising the error is the line 59. Funnily, the function should work, if the table exists. Only thing I can come up with (as in my previous edit), is that indeed for some reason the frm-file is not created during the migration process.
Why that happens is way beyond me.
I'm using South to manage my (MySQL) database tables for a Django 1.4 project, its working great.
This is a bit of a newbie question, but I'm now adding sorl.thumbnail (http://sorl-thumbnail.readthedocs.org/en/latest/installation.html#installation) to the list of installed apps in the settings file.
The instructions say that I now have to use syncdb if I'm using a "cached database key value store".
Is it OK to go ahead and use syncdb? I'm not quite sure if my MySQL+South installation counts as one. Will this mess anything up?
If i'm not wrong, when you start using south you should never use syncdb again. Instead, you should use schemamigration or other south's specific commands.
Here you can find what you were looking for. I quote here the phrase that should clear your mind:
The main use of schemamigration is when you’ve just finished your shiny new models.py and want to load up your database. In vanilla Django, you’d just run syncdb - however, with migrations, you’ll need a migration to create the tables.
In this scenario, you just run:
./manage.py schemamigration myapp --initial
That will write one big migration to create all the tables for the
models in your app; just run ./manage.py migrate to get it in and
you’re done in only one more step than syncdb!
Hope it helps!
syncdb does not interfere with South, in fact, in order to install a new app you should always use syncdb first, then apply south for migrations if you have any. So, yes, you are not going to have any problem.
I have a django application and until now I used sqLite as database backend. Now when it's quite close to production I thought of moving it all to mySQL which will be used on the box.
I reconfigured my settings to a mysql database and run
manage.py syncdb --migrate
it started creating tables and all but failed in the first (out of 40) migration with an old error (can't insert blob without key length and all that).
I first thought of manually fixing the migration files but quickly realized there is too much manual work.
So I thought ok I'll run manage.py migrate core 0040 (the last migration and that will do the trick) but it still attempts to run the initial one as well:
File "D:\~Sasha\Portman\core\migrations\0001_initial.py", line 23, in forwards
('name', self.gf('django.db.models.fields.TextField')(unique=True)),
... error message
Is there a way to migrate my models somehow without manually fixing the initial migration file and all the other magic?
First, you can't pick and choose migrations to run. migrate core 0040 means run all migrations up to 0040. In other words, it wouldn't run 0041, but it would run 0001-0040.
Now, it's side-stepping your question a bit, but if you have not moved this project to production yet, you don't actually need all those migrations. Assuming they're all schemamigrations you can rollback to zero with:
python manage.py migrate core zero
Then, delete them all (including 0001_initial.py) and simply run again:
python manage.py schemamigration --initial core
To regenerate the initial migration. It will base it off the current state of your models, negating the need for 40 migrations.
It's always a good idea to compress your migrations like this before you move new code to production. Since this is the first launch, you can remove them all and start from scratch, but in future iterations, if you generate 5 migrations during the course of development, before you commit, rollback to before the first of those, then delete those 5 and then generate a new schemamigration. The result is just one migration with all the changes of those 5. Then, you can commit that and migrate in production.
It may not solve your problem completely here, but it will definitely make things simpler to debug.
Very occasionally, I've seen problems with migrations when deploying a project on a mysql backend.
Since you are deploying a fresh copy, you do have a couple options for sidestepping the need to run all of your mightations:
First, if you want to maintain your migration history as-is, you can force syncdb to create all of your tables regardless of migrations, and then run fake migrations to get your new database up to date. That would look like:
python manage.py syncdb --all
python manage.py migrate --fake
Alternatively, if you don't care about your historical migrations, you can clear the old migrations out (just delete them) and then create a new initial migration, like:
python manage.py schemamigration --initial core
Just be sure that you also clear out the south_migrationhistory table in your dev database so that everything stays in sync between dev and prod