I just checked RT out of git and ran:
./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite
But the database type is set to ‘mysql’ in RT_Config.pm.
What gives? The schema.SQLite file still exists.
I just checked RT out of git and ran:
./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite
It helps if you don’t misspell ‘–with-db-type’
I just checked RT out of git and ran:
./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite
It helps if you don’t misspell ‘–with-db-type’
Crap. Thanks Jesse!
I just checked RT out of git and ran:
./configure --enable-layout=inplace --with-my-user-group --with-db-typ=SQLite
It helps if you don’t misspell ‘–with-db-type’
Crap. Thanks Jesse!
Slightly offtopic - is there some “best practice” limit saying when
SQLite stops being efficient and it’s time to use something bigger? Or
in other words, how large are average SQLite installations in terms of
users, tickets, etc.?
Slightly offtopic - is there some “best practice” limit saying when
SQLite stops being efficient and it’s time to use something bigger? Or
in other words, how large are average SQLite installations in terms of
users, tickets, etc.?
In my opinion, I would say that SQLite is appropriate for testing and
development work, where you have developers working on customizations of
RT. I don’t think SQLite is appropriate for production environments of
any size. But that’s just me.
Tom Lahti, SCMDBA, LPIC-1
BIT LLC
(425)251-0833 x 117
http://www.bitstatement.net/
-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Tom Lahti
Sent: Wednesday, 25 November 2009 10:55
To: Ivan Voras
Cc: rt-users
Subject: Re: [rt-users] Is SQLite no longer supported?Slightly offtopic - is there some “best practice” limit saying when
SQLite stops being efficient and it’s time to use something bigger?
Or
in other words, how large are average SQLite installations in terms
of
users, tickets, etc.?In my opinion, I would say that SQLite is appropriate for testing and
development work, where you have developers working on customizations
of
RT. I don’t think SQLite is appropriate for production environments of
any size. But that’s just me.
I’d have to completely with this.
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
Slightly offtopic - is there some “best practice” limit saying when
SQLite stops being efficient and it’s time to use something bigger? Or
in other words, how large are average SQLite installations in terms of
users, tickets, etc.?
We don’t recommend that you use RT on SQLite in production, generally.
Slightly offtopic - is there some “best practice” limit saying when
SQLite stops being efficient and it’s time to use something bigger? Or
in other words, how large are average SQLite installations in terms of
users, tickets, etc.?In my opinion, I would say that SQLite is appropriate for testing and
development work, where you have developers working on customizations of
RT. I don’t think SQLite is appropriate for production environments of
any size. But that’s just me.
SQLite could be okay for very small/low-concurrency production systems.
Compare Firefox’s use of SQLite for its data stores. Of course, as you
may have experienced, the system starts to falter with several
thousand
entries in Places.sqlite (bookmarks + history).
Cambridge Energy Alliance: Save money. Save the planet.
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 
Tom Lahti, SCMDBA, LPIC-1
BIT LLC
(425)251-0833 x 117
http://www.bitstatement.net/
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 (SQLite Is Transactional,
Atomic Commit In SQLite) and concurreny issues only
affect writers (readers are fully concurrent;
File Locking And Concurrency In SQLite Version 3,
SQLite Frequently Asked Questions), so my question really was more
directed to real-world experiences with rt3 and SQLite rather than
rumours
In defence of SQLite (not that I’m especially cheering for it), it
actually is ACID compliant (SQLite Is Transactional,
Atomic Commit In SQLite) and concurreny issues only
affect writers (readers are fully concurrent;
File Locking And Concurrency In SQLite Version 3,
SQLite Frequently Asked Questions), so my question really was more
directed to real-world experiences with rt3 and SQLite rather than
rumours
It wasn’t the last time I looked at it. I still wonder about
transaction isolation levels, but as long as RT doesn’t use BEGIN,
COMMIT or ROLLBACK, I guess that doesn’t matter much.
Tom Lahti, SCMDBA, LPIC-1
BIT LLC
(425)251-0833 x 117
http://www.bitstatement.net/