OperationalError at /swenglish/ , no such table: swenglish_entry

[rabbi]

Hi everyone,
I've gone through the Django tutorial and it worked fine when using
the default development server that is provided with Django (python
manage.py runserver)

I want to deploy my little test site though, so I've been trying to
get it running on Apache and I keep getting this error:
"OperationalError at /swenglish/
no such table: swenglish_entry"

The error seems to be happening on this line:
"entry_list = [e.eng_val + " = " + e.swe_val for e in Entry.objects.all
()]"

Apache and mod_python work with a "hello world" test

I'm running:
Windows XP (sorry)
Python 2.5.4
mod_python 3.3.1
Apache 2.2.11

Thanks in advance for any help you can give me!

[rabbi]

I forgot to mention, I'm using SQLite3

[Daniel Roseman]

Well, have you created the table? Did you run manage.py syncdb?
--
DR.

[Malcolm Tredinnick]

On Tue, 2009-01-06 at 11:59 -0800, rabbi wrote:
[...]

> I want to deploy my little test site though, so I've been trying to
> get it running on Apache and I keep getting this error:
> "OperationalError at /swenglish/
> no such table: swenglish_entry"
>
> The error seems to be happening on this line:
> "entry_list = [e.eng_val + " = " + e.swe_val for e in Entry.objects.all
> ()]"

So the error is telling you that the database table doesn't exist for
the Entry model. Did you remember to run "python manage.py syncdb" after
creating the models?

Regards,
Malcolm

[rabbi]

>>I've gone through the Django tutorial and it worked fine when using
>>the default development server that is provided with Django (python
>>manage.py runserver)

yeh, like I said. it works fine with the django-provided development
server

i've now got it running on apache/mod_python too, but i had to
hardcode the entire path to the db file in settings.py:
"DATABASE_NAME = 'C:/Documents and Settings/Rabbi/Desktop/Django
Code/mysite/vocab'"

is this really necessary or is there a nicer way that will work
anywhere?

[Malcolm Tredinnick]

On Tue, 2009-01-06 at 15:12 -0800, rabbi wrote:

[...]

> i've now got it running on apache/mod_python too, but i had to
> hardcode the entire path to the db file in settings.py:
> "DATABASE_NAME = 'C:/Documents and Settings/Rabbi/Desktop/Django
> Code/mysite/vocab'"
>
> is this really necessary or is there a nicer way that will work
> anywhere?

Ah.. that change makes sense. SQLite is a nice database in some ways,
and one of the things it does is not require you to create the database
file ahead of time (it's created when you first access it, although it
will be empty). The drawback is that if you misspell of mis-specify the
database path in any way, a new file is created or accessed somewhere
and will, indeed, be empty. Which is what you were seeing.

You do need to specify the full path to the database file in your
settings like the above. It's the only way the webserver can know where
it is (your previous setting, whatever it was, happened to work by
accident when you were using "runserver", since it was a relative path
that just happened to be correct relative to where you were running
from).

Generally, the settings file for a project is one of the things you
should expect to have to make small changes to as you move a collection
of apps around between machines or installations. If you're careful,
when developing, you should be able to set things up so that it's the
*only* file you need to worry about tweaking and even possibly split it
up into settings that are always valid and things like the above,
path-sensitive value, that you know you need to change. Some people put
the stuff they always need to change -- those settings which are
machine-specific -- into a file called, say, local_settings.py and then,
at the end of their settings.py, they write

try:
from local_settings import *
except ImportError:
pass

The try...except is just in case you may not always have a
local_settings file, but if you know it's always going to be there, you
might leave out that try...except. Also, by putting this at the end, any
local_settings values will override the previous settings values, which
provides a good way to change things as well.

Regards,
Malcolm

[rabbi]

thanks a lot malcom, that's great advice.
for the record, initially i had "DATABASE_NAME = 'vocab'"

i have another question; after changing from runserver to apache the
django admin page now looks very ugly... it's lost all formatting etc

is this normal or is it a problem i can repair. maybe the admin
templates can no longer be located?


On Jan 7, 12:23 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Malcolm Tredinnick]

On Tue, 2009-01-06 at 15:33 -0800, rabbi wrote:
> thanks a lot malcom, that's great advice.
> for the record, initially i had "DATABASE_NAME = 'vocab'"
>
> i have another question; after changing from runserver to apache the
> django admin page now looks very ugly... it's lost all formatting etc
>

The development server helps you out (and gives false expectations in
the process if you're not paying attention) by automatically serving up
the CSS and Javascript files. This isn't the case when you switch to a
real webserver, since you need to tell the webserver how to find those
files. Django isn't going to automatically serve things like CSS,
images, and Javascript, as they're static files and web servers can do a
much better job serving them and providing things like expiry times than
running it through a Python program.

This is where I unfortunately have to say "read the documentation,"
since we've spent more than a few hours writing up instructions about
this. Have a look at

http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#id1

(in fact, read that whole page if you haven't done so already). You
might need to also look up the appropriate documentation in the Apache
manuals (e.g. if you don't know what the Location directive means), but
hopefully things should be reasonably clear if you're already familiar
with Apache configuration a bit and/or take your time.

Regards,
Malcolm

[rabbi]

i was actually already reading that page... but it's 1:00am and maybe
i glazed over it without registering :)

i've now temporarily fixed my admin page problem by just copying all
files to the apache document root, but later i will need to learn what
a "symbolic link" is as it sounds like a nicer solution

the online documentation is excellent by the way!
this is the first time ive tried web development, first time ive used
HTML, python, django, any web server, etc and ive managed to get a
basic site up and running largely thanks to the documentation

much appreciated
alex

On Jan 7, 12:52 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Malcolm Tredinnick]

On Tue, 2009-01-06 at 16:07 -0800, rabbi wrote:
> i was actually already reading that page... but it's 1:00am and maybe
> i glazed over it without registering :)
>
> i've now temporarily fixed my admin page problem by just copying all
> files to the apache document root, but later i will need to learn what
> a "symbolic link" is as it sounds like a nicer solution

You said you were using Windows XP. So, out of the box, symbolic links
won't work. I believe there are tools that allow you to create them if
the filesystem is NTFS, but since the last time I used Windows in any
serious fashion was 1998, I'm not in any position to recommend anything.
It's just one of those limitations you have to accept when choosing
Windows (every OS choice has trade-offs).

Regards,
Malcolm