BugzillaORM — различия между версиями

Версия 01:42, 6 марта 2012

В Bugzilla половина кода в шаблонах, половина на основе полу-ORM’а Bugzilla::Object. Большая часть — говнокод. С одной стороны — ORM бы туда, было бы классно, НО! ORM мало, и нужен не он! Все (существующие) ORM-движки — это просто объектный интерфейс к базе данных. А нужно некое объектное ядро, которое бы позволяло создавать свои объекты, с полями различных типов, в том числе и ссылающимися на другие такие же объекты, с возможностью приписывания специальных особенностей полю, с общим механизмом хранения истории и с автоматическим базовым CRUD-интерфейсом.

Есть сущности:

• баг
• классификация, продукт, компонент
• тег (ключевое слово / keyword), milestone, версия, статус бага, agreement (пример кастомного поля)
• вложение, комментарий, флаг, тип флага
• пользователь, группа
• если таки будет ядро - ещё появляется метакласс сущности, объекты которого описывают типы сущностей

Причём, понятное дело, если баг принадлежит к некоторому продукту (через компонент), то и его версия, milestone, agreement должны принадлежать к тому же продукту. Сейчас в Bugzilla это реализуется так — для каждой сущности, связанной с багом, в баге есть «поле», а для ограничения значений полей поля делаются «зависимыми» от других полей. Из-за этого там куча костылей и, по сути, повесить зависимость на отличное от поля «продукт» поле невозможно.

А подумав и посмотрев на красивую картинку выше, мы приходим к другой идее — есть сущности, связи между ними и идея непротиворечивого состояния.

Правда, на это ещё навёрнуты права (в Bugzilla рулятся на уровне продукта) и скрытие/показ полей бага в зависимости друг от друга.

У сущностей есть:

• ID — первичный ключ
• атрибуты
• ссылка на контролирующее поле и значения — то есть если другая сущность ссылается на эту, другим полем она должна ссылаться и на контролирующую
• способ преобразования в строку
• Возможно, права доступа к сущности — привязка действий над сущностью (просмотр, правка, возможно, другие) к группам пользователей. Возможно, не нужно это сюда пихать.

У каждого атрибута есть:

• Тип
• Значение по умолчанию
• Вид показа в интерфейсе
• Копируется ли значение атрибута при клонировании сущности
• Показывается ли атрибут в форме создания сущности
• Ссылка на контролирующий атрибут той же сущности, что и этот, и на его значения

  Если выбрано, означает, что атрибут показывается, только если другой атрибут той же сущности, которой принадлежит этот, имеет одно из заданных значений

В данный момент зависимые сущности в Bugzilla хранятся в денормализованном виде, то есть если мы хотим видеть поля «продукт» и «компонент» у бага, а выбранный «компонент» однозначно определяет «продукт», то всё равно хранятся и являются атрибутами бага они оба.

Типы атрибутов:

• Строка
  • E-mail адрес — особенности: опционально скрывается ради антиспама, может иметь настройки уведомлений
• Boolean
• Decimal
• Дата
• Время
• Дата+время
• Single-Select → ссылка на сущность (то есть «многие к 1»)
  • Необязательный вариант синглселекта — «1 к 1».
  • существует в частичном виде — без выбора желаемой сущности
• Multi-Select → ссылка на несколько сущностей одного типа (то есть «многие ко многим»)
  • Вариант мультиселекта — «список подчинённых» (то есть 1 ко многим). Например, список аттачментов бага, список комментов к багу.
  • существует в частичном виде — без выбора желаемой сущности
• Файл (вложение).

Email-уведомления в общем виде задаются как уведомление на поле типа email, вытаскиваемое по цепочке из сущности (например bug.product.product_watcher.email) при изменении заданных атрибутов сущности.

Поля багов перечислены ниже. Жирное «да» в колонке «можно отключить» означает, что отключать можно уже сейчас (скорее всего, через параметры типа usevotes и т. п.). Нежирное «да» в колонках «можно отключить» и «можно менять тип» означают, что чисто теоретически логика работы Bugzilla это позволяет.

Примечания:

• Все поля-ссылки на пользователей показываются в виде строки либо в виде combo-box’а, и у них есть функция валидации — она угадывает юзеров по некорректным именам.

Устаревшие поля / поля, которые ХЗ зачем нужны в таблице полей багов:

• assignee_accessible
• qacontact_accessible
• longdesc
• commenter
• longdescs.isprivate
• content
• bug_group
• flagtypes.name
• requestees.login_name
• setters.login_name

Вычисляемые поля багов:

Поля вложений:

Поля компонентов:

Что ушло бы в ORM?

• Custom Fields, то есть, управление полями багов.
• Отключение стандартных полей типа OS, Hardware.
• Изменение типов стандартных полей типа целочисленных приоритетов.
• Добавление спецполей в продукты, компоненты и т. д. — сейчас это делается в коде.
• Версионирование всех объектов. История бы хранилась унифицированно. Не было бы отдельно таблиц bugs_activity и longdescs, соответственно не было бы и тормозов при проверке «Only bugs changed between…»
• Простые интерфейсы типа CRUD (Create/Read/Update/Delete), сейчас созданные непонятно каким копипастом. В основном имеется ввиду админка.
• Права на редактирование объектов.
• Валидаторы и подсказки значений.
• Корректная валидация зависимостей полей друг от друга.
• Часть SQL-запросов, написанных ручками в коде.
• Создание новых объектов типа SCRUM карточек.
• Мохнатая логика автоматической постановки/обновления багов из обработки входящих e-mailов и Excel-импорта

• Можно было бы прикрутить статистику по любым объектам, причём с Time Machine, то есть просмотром статистики за любой прошедший момент времени. :)

Текущая логика страницы создания бага:

• выбор classification, если она включена
• classification выбрана → выбор product, если он не вообще один
• тот же выбор продукта/классификации при клонировании багов
• продукт выбран → форма создания бага
• показ корректных списков возможных значений полей:
  • типы флагов в зависимости от компонента
  • cf_agreement в зависимости от продукта
  • списки пользователей, относящихся к багу в combo-box’ы
  • опциональный запрет на ввод приоритета на основе конфигурации (letsubmitterchoosepriority)
  • список флажков — ограничителей доступа группами
• значения полей по умолчанию:
  • которые совсем по умолчанию
  • угадывание op_sys и rep_platform на основе заголовков запроса
  • версия, qa_contact, assigned_to, cc по умолчанию для компонента
  • хитрая логика для изменения списков cc при выборе компонентов
  • assigned_to=ты при выборе статуса ASSIGNED
  • показ поля resolution при выборе закрытого статуса
  • версия из cookies
  • загруженные из шаблона ввода бага
  • загруженные из клонированного бага
    • ссылка на старый аттач в описании нового клонированного бага
    • хитрая логика для CC при клонировании багов
• напоминания о вводе времени
• предпросмотр комментариев
• постановка вложения сразу при создании бага
• переключатель Show Expert Fields
• Submit по Ctrl-Enter