Bug Tracker: установка фреймворка и создание базы данных (часть вторая)

Владимир | | Ajax, CodeIgniter, htaccess, JavaScript, MySQL, PHP, Web разработка.

Сегодня я продолжаю рассказывать о разработке собственной системы отслеживания ошибок. В прошлой статье только вкратце была описана общая идея и возможности, а также показан предварительный эскиз приложения.

Но прежде чем переходить к основной теме, хочу поблагодарить всех комментаторов и особенно AmdY, Big_Shark и Алексея Качаева за советы!

Первоначально я планировал доделать приложение полностью, и только потом опубликовать этот цикл постов. Но так получается даже лучше. Всегда есть шанс, что читатели найдут недостатки, и мне не придется переделывать все приложение чтобы их исправить 😉

В прошлый раз с инструментами мы определились (используем PHP, фреймворк CodeIgniter, MySQL и jQuery).

Сейчас нам нужно их установить и настроить.

Я предполагаю, что web сервер, PHP и MySQL у вас уже настроены, поэтому нам нужно только скачать CodeIgniter и jQuery. После этого распаковываем архивы в какую-нибудь папку на сервере. В результате должна получиться примерно следующая структура папок.

index.php
.htaccess
system/
js/
	jquery-1.3.2.min.js
css/

Файл index.php и папка system – из дистрибутива CodeIgniter.

.htaccess – самый обычный. Сразу приведу его содержимое.

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /

	RewriteCond %{REQUEST_URI} ^system.*
	RewriteRule ^(.*)$ /index.php?/$1 [L]

	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteCond $1 !^(index\.php|images|robots\.txt|css|js)
	RewriteRule ^(.*)$ index.php?/$1 [L]
</IfModule>

<IfModule !mod_rewrite.c>
	ErrorDocument 404 /index.php
</IfModule>

Основное его назначение – автоматически подставлять index.php в ссылки. Т.е. ссылка вида

bugtracker.local/bugtracker/page/2

будет преобразована в

bugtracker.local/index.php/bugtracker/page/2

При этом преобразование происходит, только если указанного в URL файла на самом деле не существует. Т.е. если запрос будет к js или css файлу, то index.php подставляться не будет.

Кстати, если вы хотите, чтобы приложение находилось в какой-нибудь папке (например, mysite.domen/bugtracker/), то нужно будет изменить параметр RewriteBase.

На настройке CodeIgniter подробно останавливаться не буду. Просто перечислю файлы, в которые нужно внести изменения.

Все конфигурационные файлы находятся в папке system/application/.

autoload.php – загружаем библиотеку для работы с базой данных и URL хелпер

$autoload['libraries'] = array('database');
$autoload['helper'] = array('url');

config.php – здесь указываем адрес приложения, например,

$config['base_url'] = "http://bugtracker.local/";

и добавляем ещё один параметр

$config['bugs_per_page'] = 5;

Как несложно догадаться его значение определяет количество записей о багах на странице.

routes.php – тут нужно указать только название контроллера, который будет использоваться по-умолчанию. Я решил его называть bugtracker.

$route['default_controller'] = "bugtracker";

database.php – здесь заполняем массив с параметрами подключения к базе данных.

Примечание. Подробнее о настройке фреймворка можно почитать в статье «PHP framework CodeIgniter. Установка и настройка.»

Теперь переходим к созданию базы данных.

Нам потребуются три таблицы:

1) bugs – используется для хранения информации о найденных багах и комментариях к ним.

Поля:
id – первичный ключ;
title – заголовок;
uname – имя пользователя, который оставил сообщение;
categoryid – id категрии к которой относится баг (должно совпадать с соответствующим полем в таблице categories);
description – описание бага;
status – здесь будет храниться информация о состоянии бага (по-умолчанию, «не исправлено»);
replyto – это поле устанавливает связь между багами и комментариями к ним (подробнее на этом мы остановимся чуть позже).

2) categories – список категорий.

Поля:
id – первичный ключ;
link – ссылка на категорию (латинскими буквами);
name – названии категории.

3) users – информация о пользователях. В данном случае этими пользователями будут только администраторы баг трекера. Оставлять сообщения и комментарии сможет кто угодно без авторизации.

id – первичный ключ;
name – имя пользователя;
pass – пароль.

Теперь посмотрите на запросы, которые создают эти таблицы.

CREATE TABLE `bugs` (
	`id` int(11) NOT NULL auto_increment,
	`title` varchar(300) NOT NULL,
	`uname` varchar(100) NOT NULL,
	`categoryid` int(11) default NULL,
	`description` text NOT NULL,
	`status` varchar(100) NOT NULL default 'не исправлено',
	`replyto` int(11) default NULL,
	PRIMARY KEY  (`id`),
	KEY `replyto` (`replyto`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

ALTER TABLE `bugs`
	ADD CONSTRAINT `bugs_ibfk_1` FOREIGN KEY (`replyto`) REFERENCES `bugs` (`id`) ON DELETE CASCADE;

CREATE TABLE `categories` (
	`id` int(11) NOT NULL auto_increment,
	`link` varchar(100) NOT NULL,
	`name` varchar(300) NOT NULL,
	PRIMARY KEY  (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

CREATE TABLE `users` (
	`id` int(11) NOT NULL auto_increment,
	`name` varchar(100) NOT NULL,
	`pass` varchar(100) NOT NULL,
	PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Самый интересный момент здесь касается таблицы bugs, а точнее её поля replyto. Оно даёт возможность отличить комментарий к багу от самого бага. Если значение в нём не равно NULL, то это комментарий, если равно – баг. При этом число, записанное в поле replyto, указывает, к какому багу относится данный комментарий.

Например, в таблице есть четыре следующий записи:

id title … replyto
1 Bug 1 … NULL
2 Comment 1 … 1
3 Comment 2 … 1
4 Bug 2 … NULL

Это означает, что мы имеем два бага (записи 1 и 4) и два комментария (записи 2 и 3), которые относятся к первому багу.

Кстати, значение поля categoryid для всех комментариев равно NULL.

Тут возникает проблема. Что будет с комментариями, если мы удалим баг к которому они относятся? Можно, конечно, решить эту проблему так:

1) найти все комментарии, которые относятся к данному багу;
2) удалить их;
3) удалить сам баг.

Но будет лучше, если движок MySQL автоматически удалит все связанные комментарии при удалении бага.

Для этого мы объявляем поле replyto внешним ключом (т.е. связываем его с полем id) и указываем опцию ON DELETE CASCADE (каскадное удаление) (строки 13-15). Теперь при удалении записи у которой поле id = 3 движок БД будет искать в этой же таблице все записи у которых replyto = 3 и удалять их.

И, кроме того, это поле (replyto) мы будем использовать при выводе сообщений о багах на страницах нашего баг трекера.

Но об этом в следующий раз.

До встречи!

Интересно почитать:
Слушать радио онлайн