I’m looking at adding a couple fields to the tickets table and I want to
make sure I understand how to properly link those fields in with RT and
DBIx::SearchBuilder.
First a little background: We have a requirement to display information
in a search that indicates if the requestor is the last person to
communicate (Create, Reply, Comment) on a ticket. We identified
colorizing the subject as a great way to display this info, but we’ve
had issues getting good results.
First, we parsed throught each ticket’s transactions to find the last
Create, Reply, or Comment and then colorize the subject based on that
person’s relationship to the ticket. But this slows the query down a lot.
Second, we compromised and just used the LastUpdatedBy field which is
fine for now (even though any transaction type determines this), but
when we start auto-increasing priority this data will not be useful.
So now, what I want to do is add two fields to the ticket table:
LastMessage(Date), LastMessageBy (principalID), which will be like
LastUpdated/LastUpdatedBy except only be modified by
Create/Reply/Comment transactions.
To have DBIx::SearchBuilder check a new field do I just need to add it
to the _CoreAccessible subroutine and create a _LocalAccessible
subroutine? Then All I’d need to do is add methods to get and set values
with _Value and _Set?
Joby Walker
ITI SSG, University of Washington
Hi Joby,
We’ve shied away from modifying core RT tables - we’ve ben afraid it would
make upgrades much more painful. We’ve extended some tables by using
attributes instead. You can mod the perl code to make the API look as
though the attributes are fields in the table.
Good luck,
Steve
At Tuesday 10/25/2005 01:54 PM, Joby Walker wrote:
I’m looking at adding a couple fields to the tickets table and I want to
make sure I understand how to properly link those fields in with RT and
DBIx::SearchBuilder.
Hi Joby,
We’ve shied away from modifying core RT tables - we’ve been afraid it would
make upgrades much more painful. We’ve extended some tables by using
attributes instead. You can mod the perl code to make the API look as
though the attributes are fields in the table.
Another alternative would be a new table…
Good luck,
Steve
Stephen Turner
Senior Programmer/Analyst - Client Support Services
MIT Information Services and Technology (IS&T)
Yeah we’re using attributes for many things, but I want this to run as
fast as possible, and while faster than parsing the transactions for a
ticket this would still require loading this attribute for each ticket
displayed on the page. Additionally, I’m trying to minimize the number
of DB queries per page load…
Joby Walker
ITI SSG, University of Washington
Stephen Turner wrote:
I’d love the same functionality. But I’d be a bit nervous
about extending the schema this way, unless Jesse wanted
to incorporate it into the mainstream.
I think there is an Attributes table for extending use.
And as someone recently pointed out to me, we could use
a custom field (+ scrips) to maintain this info, as well.
bobg
To have DBIx::SearchBuilder check a new field do I just need to add it
to the _CoreAccessible subroutine and create a _LocalAccessible
subroutine?
I believe you just stick them in _LocalAccessible.
Then All I’d need to do is add methods to get and set values
with _Value and _Set?
Ah, no, searchbuilder does those automatically.
Jesse
Hi Joby,
We’ve shied away from modifying core RT tables - we’ve ben afraid it would
make upgrades much more painful.
Agreed. Some of the stuff we’re working on for the next big thing should
make that sort of thing much easier. But currently, it does sort of
scare me.
I’d love the same functionality. But I’d be a bit nervous
about extending the schema this way, unless Jesse wanted
to incorporate it into the mainstream.
I’ll certainly take a look at the patch once Joby’s got it together.
I’m a bit of a database heretic and I don’t mind the denormalization, if
it serves a nice useful purpose 