[Rt-devel] multiple primary keys?

[Josh England]

On Thu, 2006-06-29 at 17:33 -0400, Todd Chapman wrote:
> On Thu, Jun 29, 2006 at 03:23:08PM -0600, Josh England wrote:
> > On Thu, 2006-06-29 at 14:13 -0700, Jim Meyer wrote:
> > > Hello!
> > > 
> > > On 6/28/06, Josh England <jjengla at sandia.gov> wrote:
> > > > On Wed, 2006-06-28 at 20:16 -0400, Todd Chapman wrote:
> > > > > A little of the subject, but why not use a Ticket or Asset to
> > > > > store your events?
> > > >
> > > > I'm looking to use RT with AT along with some stuff for tracking events
> > > > (ET?) to track system events often *related* to assets and only create
> > > > tickets for assets that need to be serviced.  Events just seem to me to
> > > > be a different beast, similar to tickets, but not really the same.
> > > >
> > > > Tickets and Assets are functionally different and a little too
> > > > heavyweight for the number of events I might need to process.  It takes
> > > > over 2 hours to add 4500 assets (with custom fields) to the database.
> > > > So far, with a lightweight Event object (with no custom fields), I'm
> > > > adding 862 events/sec.  I haven't timed ticket creation, but I might
> > > > look at that tomorrow.
> > > 
> > > Perhaps you should be using creating RT::Transactions for your events?
> > > Much less heavyweight, already have the concept of relating to Tickets
> > > (and probably Assets, though I've not looked at Todd's AT extension).
> > > I haven't tried creating transactions without a ticket, but in my
> > > admittedly fuzzy recollection of the code it seems tractable.
> > 
> > Maybe, but the catch is...I want to inherit from DBIx::SearchBuilder in
> > order to be able to tie in to the Query Builder Interface.
> 
> I think with so many events per second you will want to run closer
> to the metal than SB. You could use SB for querying. Your main
> desire seems to be using Query Builder. Will your events be
> using custom fields?

Using Query Builder was a strong factor for using SB.  I do need to add
custom fields to events, and I'm currently looking tying custom fields
to an EventTracker::Type object similar to how AssetTracker does it.
When this is done, I'll time adding events along with custom field data.
My guess is that it will be *much* slower.  Using my own SQL for inserts
and SB for queries might be a good idea.

With respect to Query Builder with AssetTracker...how hard would it be
to add Asset Custom Fields to the Query Builder?  This will be key for
what I'm trying to do.  I'd like to query particular custom field values
of Assets (and Events).

-JE