Re: Django 1.9 ./manage.py migrate error

That works for me. You save my life. Thank you!

On Friday, June 3, 2016 at 12:26:04 PM UTC-4, Tejesh Papineni wrote:

its working when already have a db because views.py are using Models from already existing db. But when creating new db, code in views.py is trying to access Models that have not yet been built using ./manage.py migrate. My solution is to comment code in views.py that accesses Models or try except with OperationalError , then run migrations (which will work now). Afterwards revert to old views.py code.

On Monday, March 7, 2016 at 4:20:16 AM UTC+5:30, Xuton Ion wrote:

Hi, thanks for the reply.
So, did you have a db in the project? I cloned the project again and tried to create the db from the model, but using your suggestion doesn't work.
I can only get 1.9 working if I already have a db from 1.8, but not creating a new one from scratch.

Neither the first or second line runs, they both exit with the same error. Table doesn't exist

On Monday, 18 January 2016 08:08:38 UTC+13, Marisa DeMeglio wrote:

Ok I had to run these commands to make it work:

$manage.py makemigrations <app_name> 

$migrate --fake-initial.

(for reference: django 1.9.1 / sqlite / OSX / python 3.4)

On Sunday, January 17, 2016 at 9:48:22 AM UTC-8, Marisa DeMeglio wrote:

Did you ever figure this out? I just upgraded from Django 1.8 to 1.9 and I'm having the same issue.

On Saturday, December 12, 2015 at 10:01:39 PM UTC-8, Xuton Ion wrote:

Thanks for the assistance so far.

Reading https://docs.djangoproject.com/en/1.9/topics/migrations/ it says I should be able to run migrate to apply migrations.

But does this mean I have to manually do something, or should that work the same as it did on 1.8?

I am assuming that it should also be able to create the database from the model with just running that one command.

When creating a new project the migrate line runs fine, so it seems to be something specific to the project. I cant share the project though

On Saturday, 12 December 2015 19:14:55 UTC+2, Tim Graham wrote:

Is there a reason you can't use migrations? --run-syncdb is really only meant for huge projects (hundreds or thousands of models) where migrations are too slow. Not sure why it's not working though. You'd have to project a sample project for me to debug further.

On Saturday, December 12, 2015 at 11:53:37 AM UTC-5, Xuton Ion wrote:

No, I haven't added any migrations. 

I did try with --run-syncdb though, and still had the same error though

On Saturday, 12 December 2015 16:26:15 UTC+2, Tim Graham wrote:

Does your application have migrations? Quoting the 1.9 release notes, "Automatic syncing of apps without migrations is removed. Migrations are compulsory for all apps unless you pass the --run-syncdb option to migrate."

On Saturday, December 12, 2015 at 8:42:58 AM UTC-5, Xuton Ion wrote:

Hi

I seem to have an issue with running migrate and have been googling all day without any luck

I have an app which works and runs on 1.8

After cloning the repo and creating a new ve, I ended up with Django 1.9

Running the ./manage.py migrate creates the database, but none of the tables from the model. It returns

django.db.utils.OperationalError: no such table: table_name

If I delete the db.sqlite3 (still in dev so not postgress yet), deactivate my ve and use my ve with django 1.8, the migrate line runs fine. 

If I then re-activate my ve with 1.9, everything works fine. I can make changes and run makemigrations, and it works. But the initial state seems to not work

Anyone else have the same issue, or have some advice for me?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3cfe5ec1-1643-415c-a299-80bd8135b711%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.