New data field in models.py "does not exist".

[dennis breland]

All works fine before making this change.

I added new data named "photo" in models.py and admin.py
When I bring up the web page, I get this:

ProgrammingError at /admin/recipe/dish/

column recipe_dish.photo does not exist
LINE 1: ...ipe_dish"."dish_category", "recipe_dish"."style", "recipe_di...
                                                             ^

Request Method:  GET
Request URL:  http://104.236.74.80/admin/recipe/dish/
Django Version:  1.6.1
Exception Type:  ProgrammingError
Exception Value:  

column recipe_dish.photo does not exist
LINE 1: ...ipe_dish"."dish_category", "recipe_dish"."style", "recipe_di...
                                                             ^

Exception Location:  /usr/lib/python2.7/dist-packages/django/db/backends/util.py in execute, line 53
Python Executable:  /usr/bin/python
Python Version:  2.7.6
Python Path:  

['/home/django/django_project',
 '/home/django',
 '/usr/bin',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-x86_64-linux-gnu',
 '/usr/lib/python2.7/lib-tk',
 '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload',
 '/usr/local/lib/python2.7/dist-packages',
 '/usr/lib/python2.7/dist-packages']

 

 

Here's all the data -

models.py:

.

.

class Dish(models.Model):
    dish_name = models.CharField(max_length=200)
    steps = models.TextField(default='1. Mix some stuff')
    def __str__(self):              # Do this for every class.
        return self.dish_name       # No matter which object is called, the name field is returned.

    description = models.TextField(default='Does this dish have a story?')
    ingredients = models.TextField(default='1. Sugar ')
    utensils = models.TextField(default='1. Bowl')
    cook_time = models.CharField(max_length=20, default='1 hour, 20 minutes')
    prep_time = models.CharField(max_length=20, default='20 minutes')
    dish_category = models.CharField(max_length=20, choices=FOOD_CATEGORIES)
    style = models.CharField(max_length=20, choices=FOOD_STYLE)

    photo = models.CharField(max_length=20, default='photodefault')

.

.

 

admin.py:
.
.

class DishAdmin(admin.ModelAdmin):
#    fields = ['dish_name', 'style', 'dish_category','steps','ingredients','utensils','cook_time','prep_time','description']

    # list_display is optional. When not used, the str() of each object is displayed.
    # This list contains the columns that are displayed on the Dish list page.
    # These items are the field names in the class Dish (with underscores replaced with spaces) that is defined in models.py
    # Not every field in the class is required to be here, only those desired.
    list_display = ('dish_name', 'style', 'dish_category')

    search_fields = ['dish_name']

    fieldsets = [
        ('None',        {'fields': ['dish_name', 'style', 'dish_category', 'photo',  'steps', 'ingredients', 'utensils']}),
        ('Times',       {'fields': ['cook_time','prep_time'],'classes': ['collapse']}),
        ('Description', {'fields': ['description'],'classes': ['collapse']}),
    ]

.
.

I ran these after making the changes:
    python manage.py sqlall recipe
    python manage.py syncdb

 

python manage.py sqlall recipe
BEGIN;
CREATE TABLE "recipe_site" (
    "id" serial NOT NULL PRIMARY KEY,
    "locations" varchar(200) NOT NULL
)
;
CREATE TABLE "recipe_dish" (
    "id" serial NOT NULL PRIMARY KEY,
    "dish_name" varchar(200) NOT NULL,
    "steps" text NOT NULL,
    "description" text NOT NULL,
    "ingredients" text NOT NULL,
    "utensils" text NOT NULL,
    "cook_time" varchar(20) NOT NULL,
    "prep_time" varchar(20) NOT NULL,
    "dish_category" varchar(20) NOT NULL,
    "style" varchar(20) NOT NULL,
    "photo" varchar(20) NOT NULL
)

 

 

[James Schneider]

Have you verified that syncdb ran correctly and that the column actually exists in the database?

-James

--
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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ab61c0e9-6d0d-402b-8e92-71b6804be404%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florian Schweikert]

On 12/01/15 19:16, dennis breland wrote:
> I ran these after making the changes:
> python manage.py sqlall recipe

manage.py sqlall just prints the sql statements for your models

> python manage.py syncdb

Do you use migrations?
If so did you run migrate?

What was the output of syncdb?

-- Florian

[dennis breland]

I believe this confirms the column exists:

[Vijay Khemlani]

sqlall only prints the commands that would be executed to create the database from scratch, it does not output your current database schema

if you are using django 1.7, then you need to create a migratino and apply it

python manage.py makemigrations

python manage.py migrate 

--

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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/76cfe659-f170-4c6d-a168-8386887ac77f%40googlegroups.com.

[dennis breland]

I am using Django 1.6

 

On Monday, January 12, 2015 at 1:16:17 PM UTC-5, dennis breland wrote:

[Vijay Khemlani]

Then you need to install south and configure it or update to django 1.7

--

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...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a199e98e-7805-4372-a213-033cba6a1d4d%40googlegroups.com.

[James Schneider]

The OP is running 1.6 based on the output he provided, so migrations don't apply.

You'll need to log into the database directly and interrogate the table to see what columns actually exist. The error message is coming directly from the database when the query is executed, not sourced from Django (Django is just passing it along).

You should also try running syncdb again. It should be an idempotent operation, assuming that you haven't made any other changes to your model code, so you can run it as many times as you want.

-James

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALn3ei2sb%2B01mG4FehXKe%3DsSvDc--6buHHeY16RL39BSzgDX1A%40mail.gmail.com.

[James Schneider]

Adding a column to a model is supported by syncdb, no need for South migrations. Any other operation (ie changing/deleting an existing column) would require a South migration or a manual alteration on the DB itself.

-James

[Vijay Khemlani]

I just tested it with Django 1.6.9, syncdb does not add fields to existing models

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWaoM41FFv%3DvfD5Zq_y8%2B_ES80Kh22n6okefYmQi9gMOg%40mail.gmail.com.

[James Schneider]

Apologies, Vijay is right. Syncdb will only add new tables (models) on the fly, not new columns to existing tables. It's been a while since I've had to deal with syncdb. See here:

https://docs.djangoproject.com/en/1.6/ref/django-admin/#syncdb

The OP will need to issue direct ALTER TABLE commands in the DB, or set up a schema migration using South.

If you can recreate your existing data or are still in development, you can drop the entire database and recreate it using 'syncdb', but only do that in the event you don't mind losing all data in your database. Backup your data accordingly before performing any irreversible operation. 

I'll jump on the "upgrade to 1.7" train in this case, if possible. Migrations (introduced in 1.7) will handle this situation just fine. 

-James

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALn3ei1%3DPbyUkBY1XJ1wahELt%2B07P%2Bc%3DLcHKbWzxir4dMKEs%3DQ%40mail.gmail.com.