13 521
правка
Изменения
м
На А во-вторых — если не хранить поле (например, продукт), от которого зависит другое поле (например, компонент), в самом делебаге, тоже полезут костыли (только другие). Соответственно, нужно понять, чем вообще схема, реализованная в самой багзиллесейчас, чем плоха?А вот чем:
→Идеи по созданию объектного ядра
Причём, понятное дело, если баг принадлежит к некоторому продукту (через компонент), то и его версия, milestone, agreement должны принадлежать к тому же продукту. Сейчас в Bugzilla это реализуется так — для каждой сущности, связанной с багом, в баге есть «поле», а для ограничения значений полей поля делаются «зависимыми» от других полей. Из-за этого там куча костылей и, по сути, повесить зависимость на отличное от поля «продукт» поле невозможно.
А подумав и посмотрев на красивую картинку выше, мы приходим можно прийти к другой идее — '''есть идее: сущности, связи между ними и идея непротиворечивого состояния'''(если всё это «замкнуть»). Но во-первых, это только часть картины, ибо на это ещё навёрнуты:
; Несколько ссылок на один тип: Всё это ведь не означает, что баг должен иметь только одну ссылку, скажем, на версию. Он вполне может иметь две ссылки — например, версия, в которой нашли и версия, в которой зафиксили. Последняя — это, по сути, target milestone, но ведь это не значит, что мы не можем захотеть ссылаться на сущность того же типа «версия». Или другой пример: двухуровневая техподдержка, ссылка на связанный внешний баг и ссылка на связанный внешний продукт из продукта. В конечном итоге, это можно решить присвоением «имени» ссылке, по умолчанию равному названию типа сущности, на которую ссылаемся. Это, кстати, снова становится похоже на схему с зависимыми полями :)
; Права: Сейчас в Bugzilla они рулятся на уровне продукта. TODO
; Email-уведомления об изменениях: С ними более-менее всё понятно. По сути, они всегда привязываются к какому-либо полю какого-либо объекта общей структуры, ссылающемуся на пользователя/пользователей (например, Assignee и CC бага) — это со стороны ссылок на пользователей. Вторая сторона — событие, но единственно возможные события — изменение поля или создание новой сущности.
* Значения кастом полей в таблице багов хранятся не ссылками по ID, а по именам, что создаёт геморрой для зависимых полей, так как чтобы точно идентифицировать значение, приходится брать ещё и значение поля, от которого оно зависит.
* «Поле» (селект и мультиселект) совмещено с объектом, соответственно, не добавишь дополнительных атрибутов объекту.
* История хранится только для багов, но не для остальных объектов.
* Поля не генерятся автоматически, а ручками вписываются в шаблоны.
Учитывая, что всё равно нужно вычислять «непротиворечивость» зависимостей полей, появляется следующая мысль:
* Разделяем «поля» и «объекты».
* Объекты могут содержат ссылки на другие (компонент ← продукт).
* Поле содержит ссылку на другое поле, в которое должна попадать ссылка на объект, на который ссылается объект, на который ссылается поле +))
Но тут появляется следующий вопрос: это что, всегда во все объекты тащить все связи объектов, с которыми они связаны («замыкать»)? No way! А чо делать?
== Текущее состояние ==
