2009/11/25 Tom Lahti <[email protected]>: >> SQLite's complete lack of threading model means responding to a single >> request at a time. >> >> Simply put, if you have enough users that the possibility of multiple >> people requesting information at the same time, or a user request happening >> when an external ticket comes in (email via rt-mailgate etc.), then you're >> going to be causing users to stall, waiting. >> >> You may be able to get away with it for a small number of concurrent users >> (1-5 maybe) in a low volume environment, but if you're wanting to do >> anything serious with email coming in at any moment, then you'd be better >> off setting up a MySQL/PgSQL DB. The effort isn't much different. >> >> Stuart > > I was thinking more in terms of reporting reliability. > > In short, SQLite is not ACID compliant. If underneath you are not ACID > compliant, then there is no assurance that what's in a ticket's history > necessarily reflects reality. History items may have been lost due to power > outages, locking issues, buggy web server software, etc etc etc. > > Without ACID compliance, you really don't have an audit trail. You can > pretend you do, but you really don't :)
In defence of SQLite (not that I'm especially cheering for it), it actually is ACID compliant (http://www.sqlite.org/transactional.html, http://www.sqlite.org/atomiccommit.html) and concurreny issues only affect writers (readers are fully concurrent; http://www.sqlite.org/lockingv3.html, http://www.sqlite.org/faq.html#q6), so my question really was more directed to real-world experiences with rt3 and SQLite rather than rumours :) _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [email protected] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
