DBIx::SearchBuilder 1.10_01 - major caching change

RT Developers
1

I just uploaded DBIx::SearchBuilder 1.10_01 to CPAN. This test version
includes a rewritten SearchBuilder::Record::Cachable, which now uses
the new Cache::Simple::TimedExpiry which also just debuted on CPAN.
In a stress test here, it seemed to be significantly more memory
efficient than older versions of DBIx::SearchBuilder, as well as 4x as
fast over a 4,000 user import.

Feedback would be much appreciated.

Jesse

2

Hello everybody,

I’m in the process of writing a custom application on top of RT
(currently the 3.0.11 debian package) similar to RTIR (from which I
heavily rely on in terms of code and ideas).

I make heavy use of custom fields and use several queues to sort
my requests. For 7 queues, I have defined the same set of CFs.
There will be other queues which will have a different set of CFs.

Now, when I move a ticket from one queue to another, no changes
are made to the CFs inside the database.

This leads to the fact that

TicketCustomFieldValues->Ticket->Queue is not equal to
TicketCustomFieldValues->CustomField->Queue and the fields
are no longer visible in the new Queue.

Moving the ticket back to the old queue restores the visibility
of the Cfs.

What’s the recommended way to proceed? I see the following
possibilities:

  • Make the CFs not queue-specific, but global.

    • simple
    • my custom “State” CF should have different set of
      values on some queues.

  • Add some code to retarget the TicketCustomFieldValues rows
    to the correct CustomField in the new queue.

    • full solution
    • lots of new code to write deep in the bowels of RT

  • Change my queue setup to differentiate tickets more by custom
    field and not by queue name.

    • no messing with CFs
    • UI changes necessary

Any other ideas? Or has somebody else already written code to move
CFs when changing queues?

TIA,

/ol
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >