Hi,
I’m trying to make an RTx::EventTracker package similar to the
AssetTracker integration. The thing is, in trying to make this
lightweight I’d like to move away from using ‘id’ as a primary key in my
events table. Instead I’d like to use two primary keys, timestamp and
source.
DBIx::SearchBuilder doesn’t seem to support multiple primary keys…it
complains when I try to run anything that calls _DoSearch(). However,
there is a function called LoadByPrimaryKeys (not used anywhere in RT)
that claims basic support for ‘compound’ primary keys, whatever those
are. Is there a way to use SearchBuilder with multiple primary keys or
do I have to bite the bullet and add a seemingly useless ‘id’ field to
my database table?
-JE
Hi,
I’m trying to make an RTx::EventTracker package similar to the
AssetTracker integration. The thing is, in trying to make this
lightweight I’d like to move away from using ‘id’ as a primary key in my
events table. Instead I’d like to use two primary keys, timestamp and
source.
DBIx::SearchBuilder doesn’t seem to support multiple primary keys…it
complains when I try to run anything that calls _DoSearch(). However,
there is a function called LoadByPrimaryKeys (not used anywhere in RT)
that claims basic support for ‘compound’ primary keys, whatever those
are. Is there a way to use SearchBuilder with multiple primary keys or
do I have to bite the bullet and add a seemingly useless ‘id’ field to
my database table?
A little of the subject, but why not use a Ticket or Asset to
store your events?
- compound primary key feature was never finished. I don’t think it
could be added in backward compatible way.
- Source+Timestamp is not unique pair as timestamp has not enought resolution.
Its true…if I get 2 events from the same source in the same second,
one of them would get dropped. I’m still early in the design and I’m
mostly playing around with different ideas. It sounds like I’ll have to
add an id field just to make things easy.
-JE
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.
-JE
Hello!On 6/28/06, Josh England jjengla@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.
Good luck!
–j
Jim Meyer, Geek at Large purp@acm.org
Hello!
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.
-JE
Hello!
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?
-Todd
Hello!
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
Hello!
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. 
AT QB already supports CFs.
Cool…maybe I can copy much of that stuff. I thought I had seen that
work before, but it doesn’t look to be working in my current setup. I’m
using AT 1.2.3 with RT 3.6.0. Maybe something broke with the move to
3.6.0?
-JE
AT QB already supports CFs.
Cool…maybe I can copy much of that stuff. I thought I had seen that
work before, but it doesn’t look to be working in my current setup. I’m
using AT 1.2.3 with RT 3.6.0. Maybe something broke with the move to
3.6.0?
You have to add an asset type to the query for it’s custom
fields to show up.
-Todd
AT QB already supports CFs.
Cool…maybe I can copy much of that stuff. I thought I had seen that
work before, but it doesn’t look to be working in my current setup. I’m
using AT 1.2.3 with RT 3.6.0. Maybe something broke with the move to
3.6.0?
You have to add an asset type to the query for it’s custom
fields to show up.
Ahhh…very nice. That’s pretty much exactly what I’m trying to do.
Thanks,
-JE