On Sat, Jan 9, 2010 at 2:54 PM, Philip Semanchuk <[email protected]>wrote:
> > > > But the OP was asking about accessing the database from a external process > (i.e. not Trac), so how does SQLite's threading model enter into it? > > Sorry, by 'thread' I was referring to the issue that you're talking about below, not internal threading, but locking at the application -> DB layer. Sorry for the confusion. > To the OP - multiple processes can comfortably read from a SQLite database, > but SQLite locks out writes while another query is reading. The doc says: > > The first step toward reading from the database file is obtaining a shared > lock on the database file. A "shared" lock allows two or more database > connections to read from the database file at the same time. But a shared > lock prevents another database connection from writing to the database file > while we are reading it. > > http://www.sqlite.org/atomiccommit.html > > So if you have long-running queries (as a reporting app might), it could > wreak havoc with Trac trying to write to the DB. If your reports are short, > you might be OK, but that sounds like an assumption one might eventually > regret. > This is what I was talking about, sorry for being vague :-/ > > If you don't want to move to something like Postgres, you might want to > look into making a copy of the database, or exporting relevant tables before > running your reporting app. > > Agreed, although a more robust database engine would help, it does add complexity to the system, if that's a problem, making a copy to report from is a great option too. --Scott--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
