> I'd be really happy to see what a clean DB schema for the ticket
> functionality should look like. No new functionality, just the same as
> today but in a clean structure.
Well, you asked for it. Here would be my (incomplete) approach to it.
See also the attached class diagram.
It basically centers around the idea of generic trac, but keeping a slow
transition in mind, so that not too much of the existing code must be
changed, namely:
table ticket
represents an object, having an id and a few additional fields like for
example edit_date and creation_date, creator and editor.
additionally, intrinsic properties of the ticket, for example
milestone, component, and so on will remain with the ticket object,
also the assignee and the status.
once created, ticket ids must never change.
IMPORTANT: not so the description, it will be made a system defined
ticket_field.
table ticket_field
represents a field of the ticket, either system defined or customly
defined (field_type).
it will have a value_type and multiple attributes where the actual value
then will be stored in (see for example JBPM, variable instances)
so we will have attributes for int_value, date_value, datetime_value,
string_value and so on
in this table, always the latest revision of the field will be stored,
once created, ticket field ids must never change.
table ticket_field_revision
for each change to a field, a ticket field revision will be created,
representing the old value of that field prior to change.
the ticket field revision then will be associated with a ticket revision,
which will be created for a set of atomic ticket field changes.
once created, ticket field revision ids must never change.
table ticket_revision
for each change to the intrinsic attributes of a ticket, e.g. assignee,
status and so on, along with changes to the associated ticket_fields, a
ticket_revision will be created representing the old state of the ticket
prior to change.
once created, ticket revision ids must never change.
And now for the bigger part.
Ticket comments will be moved out into a new commenting subsystem that
will provide for plugins representing resource providers/managers to reuse
existing views/logic/datamodels for their own use.
table comment
as with tickets, comments will have some intrinsic properties, for
example creator, editor, edit_date and creation_date.
in addition they have a resource_type field which determines to what
kind of resource they belong in the system, for example 'ticket'.
in addition, the actual comment is also stored in here as string.
table comment_revision
whenever a comment is edited, a new comment revision will be created
holding the old revision data prior to change.
That way, I think, we can keep changes to the ticket system at a minimum,
whilst preserving history on ticket changes and also allowing plugins to
extend the tickets by custom fields. Additionally, we introduce some sort
of type safety on individual ticket fields, be they custom or system
defined, something from which the custom time ticket fields would benefit
from ;)
And, by also moving the description to the ticket_fields table will
leverage overall queries to the system when searching or defining custom
ticket queries/reports.
As for Terje's WorkEffort thing. I personally believe that a ticket should
remain a ticket. Making it an incident, just like in for example what
Kontact uses as the base abstraction for all entries like appointments,
tasks and so on, would require a major design change. And redefining it to
something like for example a "work effort" does not capture its overall
quality of being a proposal of (even more) work.
-- Carsten
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
