install instructions are unclear about creation of db tables

[webcomm]

The installation guide at ​http://docs.djangoproject.com/en/1.2/topics/install/#get-your-database-running doesn't tell you that you need to create database tables as part of the install (if you want to use a database). The closest it comes is when it says "If you plan to use Django’s manage.py syncdb command to automatically create database tables...". But that statement is meaningless to people who are new to Django. Unless I'm missing something, there is nothing in the instructions to tell you that creating the tables is a required step (for anyone who wants to use a database).

[Karen Tracey]

But...you don't have to create the tables. That's what syncdb does, and it's generally expected you'll use syncdb unless you have pre-existing tables that you are looking to access via Django. So manually creating the tables as part of installation of the DB is not at all the expected workflow: either you'll have them already, or you'll use syncdb to create them. Perhaps if you explained exactly what snag you ran into we'd have a better idea of how to improve the doc.

[webcomm]

I was seeing this...

no such table: django_session

I wish I could tell you exactly when I saw that. It may be that my workflow was a little unusual, but I'm not sure.

The "Get Your Database Running" section was confusing to me. I wanted to use sqlite3, since that seems to be the easiest way to get started in the dev server and that's what I had remembered using in past experiments with Django. Under sqlite3, the instructions say "you don't need to do anything extra" but I wasn't sure what "extra" was in relation to. In fact, it turns out I didn't need to do *anything* to get the db running, in the case of sqlite3, but I don't think the instructions give that impression. The instructions seem to assume that the user knows to create a flat file to hold the db, and that beyond that there is nothing to run, per se. None of this is very explicit in the instructions.

I found installing the code pretty easy this time around. I think when I got the message about "no such table: django_session" was after running manage.py runserver.

[anonymous]

I get the same error when I did the tutorial and I am setting up / trying to access the admin page using 1.2.1 on ubuntu

[anonymous]

forgot to add everything :)

Django version 1.2.1, using settings 'impicks.settings'
Development server is running at ​http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Traceback (most recent call last):

File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 280, in run

self.result = application(self.environ, self.start_response)

File "/usr/local/lib/python2.6/dist-packages/django/core/servers/basehttp.py", line 674, in call

return self.application(environ, start_response)

File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/wsgi.py", line 245, in call

response = middleware_method(request, response)

File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/middleware.py", line 36, in process_response

request.session.save()

File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/db.py", line 56, in save

session_key = self.session_key,

File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/base.py", line 152, in _get_session_key

self._session_key = self._get_new_session_key()

File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/base.py", line 144, in _get_new_session_key

if not self.exists(session_key):

File "/usr/local/lib/python2.6/dist-packages/django/contrib/sessions/backends/db.py", line 29, in exists

Session.objects.get(session_key=session_key)

File "/usr/local/lib/python2.6/dist-packages/django/db/models/manager.py", line 132, in get

return self.get_query_set().get(*args, kwargs)

File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 336, in get

num = len(clone)

File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 81, in len

self._result_cache = list(self.iterator())

File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 269, in iterator

for row in compiler.results_iter():

File "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", line 672, in results_iter

for rows in self.execute_sql(MULTI):

File "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", line 727, in execute_sql

cursor.execute(sql, params)

File "/usr/local/lib/python2.6/dist-packages/django/db/backends/util.py", line 15, in execute

return self.cursor.execute(sql, params)

File "/usr/local/lib/python2.6/dist-packages/django/db/backends/sqlite3/base.py", line 200, in execute

return Database.Cursor.execute(self, query, params)

DatabaseError: no such table: django_session

[Karen Tracey]

The error "no such table: django_session" implies you have not run syncdb before trying to run the server. The tutorial does include instructions to run syncdb, in this section: ​http://docs.djangoproject.com/en/1.2/intro/tutorial01/#database-setup, after noting that the default apps included in INSTALLED_APPS each require at least one table. (django_session is used by django.contrib.sessions). This is not a bug in runserver; there might be a lack of clarity in documentation somewhere but I'm not seeing it myself since near as I can see the doc does mention exactly what needs to be done to get things running properly.

[Russell Keith-Magee]

Marking wontfix. I can't work out what area of the docs is confusing here; the tutorial is fairly clear (to my mind) about what syncdb does.

If someone can point to a specific change that needs to be made, feel free to reopen.

[wwinham]

Just as a reference for anyone coming here with this error from google, a possible cause is the use of sqlite with a relative path for the DATABASE_NAME field. In that case, running manage.py syncdb in a different directory from where you run manage.py runserver could give you that error because you're actually using different databases. I hadn't used sqlite with django in a while, so I just ran in to that.

A full, non-relative path for the DATABASE_NAME solves this.