Perform a join where the timeframes are different

[swangertyler]

In my data, events can have children. There is data in those events that I would want to associate with the parent event. When I do my base search, sometimes I find events where the parent event is created outside of the global time picker window. The only way I can think to solve this is by I can join a sub-search and have the sub-search be a different time window?
My existing search is as follows:

"base search with sourcetype=A"
| rename display_value as parent_num
|  join type=outer parent_num
[search "second search with sourtype=A"
| dedup number sortby -sys_updated_on
| rename priority as parent_priority, number as parent_num, u_incident_type as type, 
| table parent_num, parent_priority, type, parent_assignment]
| eval type = if(parent!="*", u_incident_type, type)

This works, except when, for example, if I am looking at the past 24 hours, and the "parent" was created before. I am sure there are a number of ways to solve this, but this seems most apparent to me. I don't want to exclude the occasions when I am "missing" the data.

[MuS]

Hi swangertyler,

Don't use join for reasons.

Use multisearch instead, it will not hit any hidden limits without telling you.

Try something like this:

| multisearch 
    [ search "base search with sourcetype=A" earliest=-1d@d latest=-0d@d 
    | rename display_value as parent_num ] 
    [ search "second search with sourtype=A" earliest=-3d@d latest=-2d@d 
    | rename priority as parent_priority, number as parent_num, u_incident_type as type ] 
| dedup number sortby -sys_updated_on 
| table parent_num, parent_priority, type, parent_assignment 
| eval type = if(parent!="*", u_incident_type, type)

might need some tweaking to make it fully work, but you get an idea how it works.

hope this helps ...

cheers, MuS

[swangertyler]

I could not get this to work satisfactorily. I ended up taking what I wanted as the second search, and using a report to make a csv, then joining on an inputlookup. Curating the search and sending it to a csv should keep me from running into any of those secret limits from joins.

I have yet to figure out how to get multisearch to work as I need it to.

[briancronrath]

It will still hit secret limits of the number of rows returned by the csv exceeds whatever your maximum rows a subsearch can return is set to. If you are curating the data to a csv beforehand I'd just use the lookup command since it's already a lookup

[swangertyler]

That is a good idea/point. Do I gain anything else from using a lookup vs. join [|inputlookup etc]?

I do not think in my case that I will hit any limits.