Blog Replacement: SQLite

5 AM February 25, 2004

I’ve settled on using SQLite as the database for my blog/mini-CMS. The blog is going to be running complex queries over all the data on a regular basis, and SQLite seems up to the task.

Other bonuses for SQLite include:

  • The on-disk foot-print is simple to manage—just one file. For the few tens of megabytes I’ll have, one file is fine.
  • No daemons or server processes to worry about.
  • Seems mature, stable, and well supported.
  • The application will sit comfortably on an SQL database. There will only be a few tables, so I’m not even going to bother with an O-R mapper.

Since it only impacts the code at a few points, going with SQLite is a safe decision. If it turns out that SQLite isn’t up to the task it will be simple to replace it with another RDBMS—or even something else.

By alang | # | Comments (3)
(Posted to Software Development and Python)

Comments

At 19:20, 25 Feb 2004 soif wrote:

Even w/ SQLite, i use SQLObject. The only thing that hurt me w/ SQLite, is that i can't access to the DB while some one else (another thread for example) use it.

(#)
At 19:45, 25 Feb 2004 Pieter Claerhout wrote:

Yes, that is indeed a limitation. However, if you define a timeout that is big enough, the processes will wait untill the database is released again. Just be aware that the timeout value is in milliseconds.

(#)
At 02:17, 28 Feb 2004 Andrew Barilla wrote:

According to the pysqlite documentation the timeout is in secords:

timeout:
    A timeout value in seconds, i. e. timeout=1.5. An SQLite database can be locked by a different connection being in an transaction. The timeout value means how long to wait for the lock to be released. If after /timeout/ seconds the lock is still not released, a DatabaseError will be thrown.
(#)

Add Comment




(Not displayed)






(Leave blank line between paragraphs. URLs converted to links. HTML stripped. Indented source code will be formatted with <pre> tags.)




© 2003-2006 Alan Green