We Keep Coding

Django- Why I am getting this Programming Error

Django- Why I am getting this Programming Error When I have not declared shop_product variable anywhere .
Please help Click here to view error Image
please refer to this image of error

shop_product is the name of the database table for the model Product in the application shop.
Most likely cause for this error is that you didn't apply database migrations, or, if you did, that you didn't add the application shop to your INSTALLED_APPS.
Update:
According to one of your comments, you are trying to use SQLite, which you cannot use on Heroku, see https://devcenter.heroku.com/articles/sqlite3
But it seems you figured that out because according to the settings of your app, you are using PostgreSQL, but you have not applied your migration.
Migrations are created once with manage.py makemigrations, but you have to apply them on every database, i.e. both on your local dev environment and on the database your application running on Heroku uses. For the latter, try this:
heroku run python manage.py

From the partial SQL query in the image it seems that "shop_product" is a table.
Note:
LINE 1: ... "shop_product"."id" FROM "shop_product"
Check your models if you have ShopProduct model, and check if you have migrations are updated.
Check if you have ManyToMany fields that might create that table, and also check if migrations are up to date.

Why Django 1.7 move from syncdb to migrate?

I am trying to understand the difference between syncdb and migrate on Django 1.7, I have read some stack post about the difference. I get that it depends on the version, that the next version of Django will implement "migration" and that for now, South is an external app, etc.
But what is the difference beyond the scene, I mean technically speaking? What does migrate do differently?

I agree with Maxime: Check out Andrew Goodwin's talk - Designing Django's Migrations. It's a great place to start.
We've also put together a series on Django migrations:
Part 1: Django Migrations - A Primer
Part 2: Digging Deeper into Migrations
Part 3: Data Migrations
Video: Django 1.7 Migrations - primer
Take a look at the first article to see the differences between syncdb and migrate, while the second article details everything that happens behind the scenes.

From Django 1.7, the framework implements a built-in migration system. As you said, there is already South for that but it was an external module. When you were using Django in the past and you modified a model already created in database, you had to make alter the table "by hand" if you didn't use South. syncdb was only creating the table the first table and could not update it when the model was changed.
The 1.7 release notes says:
Django now has built-in support for schema migrations. It allows models to be updated, changed, and deleted by creating migration files that represent the model changes and which can be run on any development, staging or production database.
This means that when you are adding, modifying or deleting a field in a model, you can create a Python file which will applies these changes to your database. This is handy since every developer can now update their local version or the production in one simple command: manage.py migrate.
Thanks to this system, you have less errors since you do not need to report models modifications in the database by yourself, it is easier to keep an history and work with a VCS (you can go forward and backwards with migrations, or undo/redo migrations if you prefer). Indeed, these Python files created are stored in the folder <app>/migrations and there is one file per modification.
It has been integrated to Django because everyone needs it and it doesn't cost you anything to have it (runtime performance are not affected). If you want to know more about this subject, I recommend you this talk: Andrew Godwin: Designing Django's Migrations - PyCon 2014 (Youtube video - 26min)

Migrate models with from one django app to several other apps

I have a django app which consists of 17 models. Now I have realized that these models should be in 3 different apps(not in the original app). So now I would like to migrate these models out of the original app to these 3 different apps. How do I do that?
There exists foreign key, generic foreign key and ManyToMany relationships among the models. I also have data in the database(MySql), so I would like the data to be preserved during migration.
I have installed south for migrations, but don't know how to use it for solving this issue. I have gone through this similar question but could not find an answer that would solve my problem. Would be thankful for any help !

In my opinion, you have two ways of completing this task as stated below:
Move the models and add Meta.db_table to refer the existing sql table as needed as #kroolik suggested
Perform a three steps migration
The former is easier while the later could be better as tables would be named as you expect.
First of all, you mention you already has south installed. The first step would be to create the initial migration for the existing app. Take a look to the south tutorial. Then you must apply that migration, but as you already has the tables in db it would fail unless you include --fake flag.
After that you need to create the three apps you mention, and their models. Also create and apply (this time without fake flag) the initial migration for them.
Next step is write a datamigration. You must write it manually, although you can create the skeleton with datamigration. You must write "by hand" the migration.
Now you are almost done, the only remaining thing is remove the original tables. You can just remove those models, and create an "auto" schemamigration.
Don't forget to apply the migrations with migrate command. Also as #Bibhas mention a copy of database and/or a dump of it is a pretty good idea.

Migration: Creating UserProfile in Django/MySQL

I have created a UserProfile field in order to add a favorites functionality to my site. Using Django's recommendation, I created a UserProfile model as follows at the bottom
Unfortunately, I already had the rest of my database created, and so I need to either use a migration utility or manually edit my database. However, I do not have sufficient permissions to utilize a migration utility, so I have to edit the database directly, and am struggling to do so.
This answer is similar to what I want to accomplish, but I can't quite get the syntax to work in my case.
MySQL - One To One Relation?
class UserProfile(models.Model):
user = models.ForeignKey(User, unique=True)
favorites = models.ManyToManyField(Media, related_name='favorited_by')

In my experience, the best migration utility is South. Once you've installed and added it to your settings, you'll need to create initial migrations for your existing modules using
./manage.py schemamigration --initial my_module,
which will include the one containing your UserProfile model, then from there you can migrate using
manage.py migrate my_module.
The real power in using a utility like this is portability and reversibility. You can migrate forward and backward as needed, and you'll be able to bring your schema to virtually any SQL database without all the fuss of rebuilding using SQL directly.

I would certainly agree with Steves recommendation to use South.
However if you for some reason wouldn't want to, you can issue the following command:
python manage.py sql <appname>
This will output the SQL statements which django will use to create your tables. This can then be used to manually modify the database.

Django: Change models without clearing all data?

I have some models I'm working with in a new Django installation. Is it possible to change the fields without losing app data?
I tried changing the field and running python manage.py syncdb. There was no output from this command.
Renavigating to admin pages for editing the changed models caused TemplateSyntaxErrors as Django sought to display fields that didn't exist in the db.
I am using SQLite.
I am able to delete the db file, then re-run python manage.py syncdb, but that is kind of a pain. Is there a better way to do it?

Django does not ever alter an existing database column. Syncdb will create tables, but it does not do 'migrations' as found in Rails, for instance. If you need something like that, check out Django South.
See the docs for syndb:
Syncdb will not alter existing tables
syncdb will only create tables for models which have not yet been installed. It will never issue ALTER TABLE statements to match changes made to a model class after installation. Changes to model classes and database schemas often involve some form of ambiguity and, in those cases, Django would have to guess at the correct changes to make. There is a risk that critical data would be lost in the process.
If you have made changes to a model and wish to alter the database tables to match, use the sql command to display the new SQL structure and compare that to your existing table schema to work out the changes.
You have to change the column names in your DB manually through whatever administration tools sqlite provides. I've done this with MySQL, for instance, and since MySQL lets you change column names without affecting your data, it's no problem.

Of course there is.
Check out South

You'll have to manually update the database schema/layout, if you're only talking about adding/removing columns.
If you're attempting to rename a column, you'll have to find another way.
You can use the python manage.py sql [app name] (http://docs.djangoproject.com/en/dev/ref/django-admin/#sql-appname-appname) command to see what the new SQL should look like, to see what columns, of what type/specification Django would have you add, and then manually run corresponding ALTER TABLE commands.
There are some apps/projects that enable easier model/DB management, but Django doesn't support this out of the box, on purpose/by design.