On 11/11/2010 04:14 AM, cap_sue wrote:
Thanks a lot for your input and sorry that I have taken so long to respond.
I was working on other stuff and only got back to the Trac installation now.
I have no idea what that is like at all. Seriously. ;-)
(No worries)
I have successfully managed to create authentication and once logged in, I
can see the New Ticket field.
Excellent.
I have another (or a few) question(s).
Ask away.
Would it be possible to continue using sqlite for actual bugtracking
purposes or will i run out of database space soon and/or are the feature in
sqlite very limited compared to MySQL? In other wods, what would be the
advantage of going with MySQL as opposed to sqlite.
MySQL is a real database server. It has a finer granularity of locking,
better concurrency, less latency, etc.
SQLite is a database engine, suitable for small installations and
embedding into applications. It is easier to set up, as you don't have
to set up a daemon, tweak much of anything, worry that much about
security, etc.
You won't really run into space issues with either, until you run out of
disk space. You also won't (generally) run into compatibility/feature
issues as Trac is programmed to be reasonably database abstract.
However, you might run into problems with plugins which call direct SQL
commands rather than the Trac API, as they may not have been programmed
as conservatively as core Trac is. This is generally not a big deal -
fix the SQL until it works, file a bug with the plugin maintainer,
submit a patch, get on with life.
That said, you will likely run into scalability issues. If you're
supporting two users, and don't intend in going over about five people
in the near future, then don't worry about it - just use SQLite. Once
you hit about 5-10 heavy users, however, you'll start seeing issues with
people stepping on each other (you'll start seeing "database is locked"
timeout errors) and then you'll need to migrate to a real DB server.
Also note that any custom reports you do will be all on you. I've
specifically run into variances with time-related ones, as MySQL,
PostgreSQL and SQLite all have different date-handling functions. Also,
the quoting can be subtly different (PostgreSQL wants single quotes).
We do have a SnowLeopard Server which I can use to install trac once I
establish trac is working fine on my system. In that case, I do have MySQL
pre-installed on the Server OS. Would there be a big difference in the
procedure to set up the trac project if I went for a MySQL DB?
Depends on how paranoid you are and how much functionality you need.
With SQLite, you just point the ini file at the file you want to use
and, once it is created, restrict permissions so someone else can't fire
up the SQLite CLI client and modify it, while not breaking the
permissions necessary for trac to work. Generally, the correct owner and
permissions 0644 do the trick, which also means your nightly stats
gathering scripts can dump the db to, say, email each manager a summary
of the day's events.
With MySQL, you (or, at least I)
- Install it
- Create root user
- Create empty trac db
- Create trac user with access only to that db
- Point trac.ini at that DB with those credentials
- Since trac.ini now has credentials, lock it down so no one can read
it except those who need to
- Create a readonly user with SELECT permissions (so that nightly
scripts can query the DB, as mentioned above)
It's is not particularly difficult, just a little bit more work.
--
Matthew Caron
Build Engineer
Sixnet | www.sixnet.com
O +1 518 877 5173 Ext. 138
F +1 518 602 9209
matt.ca...@sixnet.com
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
