On Jan 9, 2010, at 1:29 PM, Scott Mead wrote:
On Sat, Jan 9, 2010 at 11:08 AM, David Champion <[email protected]>
wrote:
Certainly, it's at $TRAC_ENV/db/trac.db. But you might find yourself
more productive as well as upward-compatible to use the Trac API
instead.
Not only that, but sqlite is a single threaded database, so if you
got your
reporting app going you either have access from trac, or your app.
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?
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.
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.
Good luck
Philip
--
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.
