SQLite 3 support
I've just checked in initial support for using Django on top of the SQLite 3 database (it's in revision 288). While it's been tested a little bit, there are possibly still bugs, so please file a ticket if you find any rough edges.
This change should make it very simple to get up and running with Django quickly; no need to set up a database, muck with permissions, or what have you.
It's easy to use: in your settings file just set DATABASE_BACKEND to sqlite3 and set DATABASE_NAME to the full path to the database file; the rest of the database settings are ignored by the SQLite backend. You'll need to have SQLite 3 and pysqlite2 installed.
Enjoy!
Posted by Jacob Kaplan-Moss on July 21, 2005
Comments
Adrian Holovaty July 21, 2005 at 11:18 p.m.
Thanks, Robin! Fixed.
rdk July 22, 2005 at 5:47 a.m.
great, finally!
now the intro screencast could be really "1-2-Django!"
1. prepare environment (python, easyinstall, pysqlite and django eggs)
2. create app (with DB wizard - where 0. is the option for SQLite and question for DB name, models and fields def)
3 aka Django! - browse and look around :)
Gheorghe Milas July 22, 2005 at 2:05 p.m.
Great, thanks, but I have one question, are you planning on supporting Microsoft SQL Server or at least ODBC, if not then are you planning on documenting how someone else may do it?
maurycy July 22, 2005 at 5:58 p.m.
Gheorghe, if you're familiard with Python and interested in adding new database backend to Django, take a look at existing implementations. You can find them in django.core.db.backends package.
Mark Eichin July 22, 2005 at 8:49 p.m.
Ok, so much for getting anything *else* done this weekend :-) Thanks!
Giles Brown July 23, 2005 at 7:20 a.m.
I've had a quick fiddle at creating an ADO (via pywin32) SQL server backend and managed to get it to successfully do an "django-admin init" (probably needing a couple more tweaks to get it really right). Wasn't sure which bits were needed for the backend to work so was just fixing things that seemed to be broken as I went along. Maybe I'll get around to doing a bit more on it soon.
Adrian Holovaty July 23, 2005 at 10:57 a.m.
Giles -- That's exciting! Once you've gotten it to a point at which it's stable, please do file a ticket with your complete patch, so we can integrate it into the Django distribution.
Marcus Bajohr July 24, 2005 at 4:07 a.m.
I've started a port to the firebirdsql-database,
code will follow after first tests are successfully finished.
Marcus Bajohr July 27, 2005 at 12:02 p.m.
I'd stopped the development for the announced port to firebird , as i have to hack to deep into the system.
There are some fieldnames, which were keywords in firebird-ddl, e.g domain.
That makes me really sad, as with this decision i cannot use django.
Oh, yes, i could use postgres, mysql or sqlite - but - i am not as crazy as those "anything is possible-guys" to run several database-systems on one machine. Our database-system is the firebird, and there's no chance for me to change that for the next 300 years.
Robin Munn July 27, 2005 at 3:17 p.m.
Marcus Bajohr - Does firebird not allow you to wrap field names in quotes? That seems very odd to me, as most other database engines let you do that.
If you do end up abandoning your project, would you be able to post the work you've done so far, so that someone else might be able to finish it?
Robin Munn July 28, 2005 at 12:22 a.m.
I've added patches to ticket #121 (http://code.djangoproject.com/ticket/121) which should resolve Marcus Bajohr's problem. Marcus, if you read this, please check whether those patches solve the problem you were encountering with Firebird.
Robin Munn July 28, 2005 at 1:05 p.m.
If you're getting a traceback like the following when you run sqlite3:
"""
Traceback (most recent call last):
...
pysqlite2.dbapi2.ProgrammingError: no compiled statement - you need to execute() before you can fetch data
"""
Then you probably need to upgrade pysqlite from 2.0.2 to 2.0.3. There was a bug in pysqlite 2.0.2 that's causing this problem. See http://code.djangoproject.com/ticket/216 for details.
Marcus Bajohr July 28, 2005 at 1:38 p.m.
Robin, thanks for fast reply.
Yes, it' possible to quote the fieldnames (I'd forgotten this possibility since i haven't used it until now).
I'll test the patches tomorrow.
thanks, Marcus
Gheorghe Milas July 29, 2005 at 11:56 a.m.
I waited a little for Giles Brown to see if he will post his work on MSSQL via ADO and since I did't see anything I tried to do something myself. After some work I was able to make a patch (see Ticket# 225) using adodbapi ( http://adodbapi.sourceforge.net/) and looks like is stable.
Ian Sparks July 29, 2005 at 3:37 p.m.
Regarding Quoting Fieldnames and Firebird :
If you do this the fields become case-sensitive. So :
create table "my test"
(
"my field" VARCHAR(10)
)
select "MY FIELD" from "my test" ! Error, no such field "MY FIELD"
select "my field" from "MY TEST" ! Error, no such table "MY TEST"
select "my field" from "my test" !OK
In general, using quoting makes the database much less forgiving. But good luck, I too would like to see a Firebird supported in Django.
Jonathan September 12, 2005 at 11:11 a.m.
You should already be treating fieldnames as case sensitive.
A lot of dbs have case sensitive or case-forced APIs (ie, in oracle everything is ALLCAPS or alllower, i can't remember)
It's good form to treat things as case sensitve - most operating systems and programming languages do.
Comments are closed
To prevent spam, comments are no longer allowed after sixty days.


Robin Munn July 21, 2005 at 10:57 p.m.
Great! This will make "kicking the tires" a whole lot easier for many people.
One minor problem with the patch just committed: conf/project_template/settings/main.py has references to "sqlite" scattered throughout, which should be "sqlite3". I've submitted a ticket: http://code.djangoproject.com/ticket/147.
Looks great. Thanks for doing this!