[Rt-devel] multiple primary keys?

[Todd Chapman]

On Thu, Jun 29, 2006 at 03:40:35PM -0600, Josh England wrote:
> 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).
> 

AT QB already supports CFs. :)