Thread: [SQLObject] Using SQLObject and CherryPy
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Mico S. <mic...@gm...> - 2005-11-27 21:18:32
|
Dear all, I tried to make simple app using CherryPy + SQLObject. I wrote this model: from datetime import date, timedelta from sqlobject import * __connection__ =3D "sqlite:/d|/home/mico/personal/project/video/data.db" class Anggota(SQLObject): alamat =3D StringCol() orders =3D MultipleJoin('Order') nama =3D StringCol() class Video(SQLObject): judul =3D StringCol() bintangUtama =3D StringCol() hargaSewa =3D CurrencyCol() lamaPinjam =3D IntCol(default=3D1) bonPeminjaman =3D RelatedJoin('BonPeminjaman') class BonPeminjaman(SQLObject): tglPinjam =3D DateCol() tglKembali =3D DateCol(default=3DNone) totalHargaSewa =3D CurrencyCol(default=3DNone) pelanggan =3D ForeignKey('Anggota') videos =3D RelatedJoin('Video') def getTotalHargaSewa(self, videos): total =3D 0 for video in videos: total +=3D video.hargaSewa self._SO_set_totalHargaSewa(total) return total def getTglKembali(self, videos, tglPinjam): durasi =3D timedelta(days=3D0) for video in videos: durasi +=3D timedelta(days=3Dvideo.lamaPinjam) self._SO_set_tglKembali(tglPinjam + durasi) return tglPinjam + durasi Then, with CherryPy I wrote a class: import cherrypy from kid import Template, XML from model import * class Page: '''Class utama halaman ''' def index(self): page =3D Template(file=3D'./templates/index.kid') page.isi =3D XML(''' <p>Ini isi dari site</p> ''') return page.serialize() index.exposed =3D True def memberCheck(self, id): try: member =3D Anggota.get(int(id)) return "Member found. Name: %s" % member.nama except SQLObjectNotFound: return "Member not Found" memberCheck.exposed =3D True When I tried to run http://localhost:8080/memberCheck, I got this message: ProgrammingError: SQLite objects created in a thread can only be used in th= at sa me thread.The object was created in thread id 3404 and this is thread id 38= 48 Can you suggest me what was wrong and how to fix this? -- Mico Siahaan --- Mobile: +62-8121025010 Email: Mic...@gm... Blog: www.tentangmico.info |
From: Steve Z. <sl...@gm...> - 2005-11-28 02:21:14
|
> ProgrammingError: SQLite objects created in a thread can only be used in = that sa > me thread.The object was created in thread id 3404 and this is thread id = 3848 > > Can you suggest me what was wrong and how to fix this? see http://www.cherrypy.org/wiki/SQLObjectThreadPerConnection |
From: Brian B. <ex...@gm...> - 2005-11-28 09:54:20
|
Mico Siahaan wrote: > Dear all, > > I tried to make simple app using CherryPy + SQLObject. Take a look at the code for TurboGears (http://turbogears.org/), which uses CherryPy + SQLObject (with SQLite) and handles this issue quite nicely. -- Brian Beck Adventurer of the First Order |
From: Jorge G. <go...@ie...> - 2005-11-28 12:03:12
|
Brian Beck <ex...@gm...> writes: > Take a look at the code for TurboGears (http://turbogears.org/), which uses > CherryPy + SQLObject (with SQLite) and handles this issue quite nicely. Not just SQLite, but every other RDBMS supported by SQLObject. I'm using it with PostgreSQL, there are people using it with MySQL and so on. -- Jorge Godoy <go...@ie...> |
From: Ian B. <ia...@co...> - 2005-11-28 20:47:50
|
Mico Siahaan wrote: > When I tried to run http://localhost:8080/memberCheck, I got this message: > > ProgrammingError: SQLite objects created in a thread can only be used in that sa > me thread.The object was created in thread id 3404 and this is thread id 3848 This is a bug in SQLObject, related to SQLite having a different kind of thread safety check than other adapters. SQLObject never concurrently uses a connection from more than one thread, but SQLite doesn't like you to ever reuse a connection in a new thread. I've asked if anyone wants to make a test for this (any short repeatable script will do!), but no one ever does. So, probably out of stubborness on my part as much as anything, the bug has gone unfixed. Probably the fix is to make a method sqlobject.sqlite.sqliteconnection.SQLiteConnection.getConnection, which recreates a connection each time it is called. It depends on the overhead involved in making a SQLite connection, but I suspect the overhead is very small (?). If not, then it should keep a pool of connections, keyed by thread id, or using threadlocal storage. TurboGears and some other frameworks have a workaround for this bug, but the workaround causes some other problems. There's also an issue about using in-memory databases with SQLite, if you aren't persisting the connection. I don't know if it's possible at all in a multi-threaded environment, because of that check (unless maybe you created a worker thread and queries were queued on that thread -- which would end up serializing all queries and transactions, but at least would be slightly functional). Really SQLite needs a way of naming an in-memory database, so you can refer to it instead of always creating a new one on demand. At least that's my impression of what :memory: does. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |