Here are two examples that explain how the connected flag affects transactions. Consider having these events in descending time order
event1 mid=1
event2 foo_id=abc
event3 mid=1, foo_id=abc
event4 foo_id=abc
.... | transaction mid, foo_id
when using connected=true the following trasaction will be created: (event2 is not added because at the time it is processed we don't have an established transitive relationship between mid and foo_id)
event1 mid=1
event3 mid=1, foo_id=abc
event4 foo_id=abc
if connected=false the transaction would look like
event1 mid=1
event2 foo_id=abc
event3 mid=1, foo_id=abc
event4 foo_id=abc
connected=true means that before adding an event to a transaction the value of least one of the unifying fields must be present in at least one of the existing events in the transaction.
connected=false means that an event can be added to a transaction eventhough a transitive relation is not established between the fields already seen in the transaction and the ones present in the event
Given that we see events in the reverse time order, there are some pretty good chances that we see the transitive relation established after (earlier in time) it can be useful to us. Consider the following stream of events
time=1 action=login, user=foo
time=2 action=assing_id, user=foo, id=123
time=3 action=sendemail, id=123
time=4 action=drink beer, user=foo
is processed in splunk as follows: (so you can see that in connected=true "time=3 action=sendemail, id=123" will not be part of the transaction because it occurs before the transitive relationship betwen user and id is formed)
time=4 action=drink beer, user=foo
time=3 action=sendemail, id=123
time=2 action=assing_id, user=foo, id=123
time=1 action=login, user=foo
In 4.1 we do the right thing even when the transitive relationship is seen later - in pre 4.1 connected=false is the poor's man solution
