Query mismatching

I’m trying to run the queries below, but the answers are not desirable !

Working query without filter of last report time:
(id of computer of it as string | "N/A", id of fixlet of it as string | "N/A") of results whose (relevant flag of it = True) of bes fixlets whose (name of site of it as string as lowercase = "Enterprise Security" as lowercase AND name of it as string as lowercase starts with "ms" as lowercase)

Failing query after adding filter last report time, actually its matching incorrect IDs (computer & fixlet):
(id of computer of it as string | "N/A", id of fixlet of it as string | "N/A") of results ( (bes computers) whose (last report time of it > (now - 7*day)) , ((bes fixlets) whose (name of site of it as string as lowercase = "Enterprise Security" as lowercase AND name of it as string as lowercase starts with "ms" as lowercase AND applicable computer count of it > 0) ) )

any help will be appreciated.

The ‘relevant flag of it’ filter is not present on the second query, so you’re still including the results where the fixlet is no longer relevant on the computer.

Efficiency-wise, this has some of the same issues discussed in this thread yesterday at API - filter bes property results by bes computer group - #4 by JasonWalker

Using the tuple (bes computers, bes fixlets) means that for every BES Computer, every BES Fixlet is looked up again. If there are a thousand computers, then there are thousand repeated searches to build the list of fixlets.

It’s more efficent to retrieve all the computers first into a set, retrieve all the fixlets once into a set, and then unwind the set members to perform the lookups. This is because the lookup that retrieves the computers & fixlets takes much longer than retrieving the results or properties after the lookup is finished. I’d refactor that to

(
   id of computer of it
 , name of computer of it | "No ComputerName"
 , id of fixlet of it
 , name of fixlet of it
) of (
  results (item 0 of it, item 1 of it)
  ) whose (relevant flag of it) of
(
   /* unwinding the elements of a set is much faster than repeating the computer/fixlet lookups */
   elements of item 0 of it
 , elements of item 1 of it
) of
(
  /* build a set of interesting computers and fixlets, so those lookups are performed only once */
   set of bes computers whose (now - last report time of it < 1 * day)
 , set of bes fixlets whose (
       applicable computer count of it > 0
       AND name of site of it as string as lowercase = "Enterprise Security" as lowercase 
       AND name of it as string as lowercase starts with "ms" as lowercase          )
)

edit: I also put the fixlet filter “applicable computer count of it > 0” before the fixlet name comparison. At larger scales I think it’s probably faster to ignore the non-relevant fixlets first, and skip the string comparisons on the non-relevant fixlets.

edit 2: it’s actually much faster to filter the ‘applicable’ fixlets first, before even comparing the site name, at least on my deployment that has many subscribed sites, so I changed the order of the fixlets filters, again.

2 Likes

Want to understand it more in detail please, why we are only picking item 0 & 1, when we have 4 items, are we considering computer as item 1 & fixlet as item 2?

and same goes with these elements?

You have to read relevance like this in chunks, from right to left.

So initially it retrieves two objects, a set of computers (item 0) and a set of fixlets (item 1).

It then expands each of those sets into the individual elements, so the next stage gets a lot of single computer objects (a new item 0) and a lot of single fixlet objects (a new item 1), and gets the fixlet result objects for those computer/fixlet combinations, ready to pull the information out of the results.

2 Likes