[Багтрекингъ] Что счас модно?
Есть mantis, trac, eventum. Что именно интересует?
Скажем так - веб-трекер, где энд-юзеры и тестеры могут открывать тикеты и следить за их прогрессом.
Jira
Flyspray. Даже уведомления в любимый всеми жаббер слать умеет.
tracэта гадость все данные в блобах держит.
ютрек клевая штука
хз какая там лицензия...
хз какая там лицензия...
эта гадость все данные в блобах держит.Что именно тут блоб?
CREATE TABLE attachment (
type text,
id text,
filename text,
size integer,
time integer,
description text,
author text,
ipnr text,
UNIQUE (type,id,filename)
);
CREATE TABLE auth_cookie (
cookie text,
name text,
ipnr text,
time integer,
UNIQUE (cookie,ipnr,name)
);
CREATE TABLE component (
name text PRIMARY KEY,
owner text,
description text
);
CREATE TABLE enum (
type text,
name text,
value text,
UNIQUE (type,name)
);
CREATE TABLE milestone (
name text PRIMARY KEY,
due integer,
completed integer,
description text
);
CREATE TABLE node_change (
rev text,
path text,
node_type text,
change_type text,
base_path text,
base_rev text,
UNIQUE (rev,path,change_type)
);
CREATE TABLE permission (
username text,
action text,
UNIQUE (username,action)
);
CREATE TABLE report (
id integer PRIMARY KEY,
author text,
title text,
query text,
description text
);
CREATE TABLE revision (
rev text PRIMARY KEY,
time integer,
author text,
message text
);
CREATE TABLE session (
sid text,
authenticated integer,
last_visit integer,
UNIQUE (sid,authenticated)
);
CREATE TABLE session_attribute (
sid text,
authenticated integer,
name text,
value text,
UNIQUE (sid,authenticated,name)
);
CREATE TABLE system (
name text PRIMARY KEY,
value text
);
CREATE TABLE ticket (
id integer PRIMARY KEY,
type text,
time integer,
changetime integer,
component text,
severity text,
priority text,
owner text,
reporter text,
cc text,
version text,
milestone text,
status text,
resolution text,
summary text,
description text,
keywords text
);
CREATE TABLE ticket_change (
ticket integer,
time integer,
author text,
field text,
oldvalue text,
newvalue text,
UNIQUE (ticket,time,field)
);
CREATE TABLE ticket_custom (
ticket integer,
name text,
value text,
UNIQUE (ticket,name)
);
CREATE TABLE version (
name text PRIMARY KEY,
time integer,
description text
);
CREATE TABLE wiki (
name text,
version integer,
time integer,
author text,
ipnr text,
text text,
comment text,
readonly integer,
UNIQUE (name,version)
);
CREATE INDEX node_change_rev_idx ON node_change (rev);
CREATE INDEX revision_time_idx ON revision (time);
CREATE INDEX session_authenticated_idx ON session (authenticated);
CREATE INDEX session_last_visit_idx ON session (last_visit);
CREATE INDEX ticket_change_ticket_idx ON ticket_change (ticket);
CREATE INDEX ticket_change_time_idx ON ticket_change (time);
CREATE INDEX ticket_status_idx ON ticket (status);
CREATE INDEX ticket_time_idx ON ticket (time);
CREATE INDEX wiki_time_idx ON wiki (time);
Что именно тут блоб?Всё что имеет тип text. Т.е. почти все колонки.
(Я правил только питоний код в траке, то что было нужно из БД лежало там честными строчками)
Так там внутри что-то нечитабельное лежит?Не совсем понял вопрос.
Проблема с LOB-ами состоит в том что работа с ними происходит ОЧЕНЬ медленно, поэтому их использование везде где только можно (а уж тем более в качестве первичных ключей) считается дурным тоном.
Jiraчем она хороша?
Набором фич, интегрируемостью с остальным семейством атлассионовских продуктов
Redmine
чем она хороша?например тем что очень популярна
типа многим людям не надо будет к ней привыкать, и так уже будут знать чо это
в джире мне очень нравится что можно переходы наиразличнейшие настроить
я с другими сравнивать особо не могу (может там еще хуже) но в джире очень не нравятся дикие тормоза, неудобность ведения версий, не поддерживание таймзон
ну и поиск методом задания миллиона критериев это говно (тут я сравниваю с поиском в ютреке)
Не совсем понял вопрос.Я думал ты там нашел место где данные хранятся в сериализованном виде. Видел могучую perl-CMS где в БД лежали перловые объекты.
Проблема с LOB-ами состоит в том что работа с ними происходит ОЧЕНЬ медленно, поэтому их использование везде где только можно (а уж тем более в качестве первичных ключей) считается дурным тоном.
А касательно дурного тона: надо ж понимать когда это ограничение оправдано. Для трака оно не актуально.
opensource, на питоне, не trac (меня исходный код трака не вдохновляет).
Фичи: интеграция с vcs, с вики (физически вики лежит рядом с исходным кодом, формат — ReST/Markdown, версионирование обеспечивается vcs, а не БД возможность ответа на уведомления по почте.
Сам такого не знаю.
Для трака оно не актуально.После того, как я случайно засабмитил в свн пароль и пришлось экспортировать, править и импортировать репозитарий, трак отказался работать. Пришлось лезть в его БД чтобы выяснить причину. И вот что я там увидел (тоже самое - во всех таблицах):
У большинства полей тип text, сравнение utf8_bin. Проблему я решил, но просто стало интересно: нафига такое делать?
И вот что я там увиделПереформулировал с помощью картинки приведенную мной схему БД?
нафига такое делать?
Такое ощущение что трак написан жава-программистами. Исходный код совсем не питонский. Куча универсальности и плагинов вместо большого файла с настройками тоже ужасна
Интеграция с системой контроля версий убогая. Вики-разметка нечитабельна.
Поэтому мне-то как раз хотелось бы найти альтернативу.
Переформулировал с помощью картинки приведенную мной схему БД?Там не сериализированные объекты, а текст лежит. Или ты о чём?
Оставить комментарий
geja_03
Собсно сабж. Решения на базе мускуля приветствуются.