What's not to like about "Like"? Um...performance hit...

I use it 90% of the time TBH.

What is the official jamf distinction between "like" and "is" ?

Definitely use it pretty frequently myself...

During some breakout sessions, at Jamf Nation User Conference 2016, we were told like and not like has more performance impact to your server than is and/or is not, because more calculation is required.

I would love to see something from Jamf on these criteria and performance.

We know how to use each, what we can use Jamf feedback on, is performance related.

This way the community can be aware, and keep it in mind when designing logic.

PS, see, for a second time, I did not mention using mds for EAs. I'm so proud of myself. :)

Don

While there would be some performance differences, really it's NOT about that..

The difference between: ( is, is not ) and ( like, not like ) is often (though not exclusively) more to do with "Data Types".

is / is not: is obviously doing an equality match
while: like / not like: is obviously doing a fuzzy match (which is more computationally expensive)

Sometime there is no choice - if you want to get the criteria correct, sometimes you have to use the fuzzy 'like' match criteria. An Example would be Version Strings like: 16.0. ... ( 16.0, 16.0.0, 16.0.12 )
where it makes no sense to do 'an exact match'

Of course if you can do an exact match, then you can use: is / is not
So that's what it boils down to.. the 'Type of information involved' and whether or not you can use exact match criteria, or whether you need to use fuzzy match criteria.

I'd like to see some more options like "Starts with". We use two character abbreviations for the school districts we work with and I'd imagine not having to search the whole string for something that is short and known to be at the beginning would save some resources.

This is a good topic. Can it be looked at from the standpoint of pure mySQL? In other words, is the JSS (No I will not stop using that!) involved beyond creating the query from the criteria?

I would expect Jamf to have really good mySQL architects and DBAs, yet I am unaware of a white paper providing guidance on this. I've heard generalities like 'don't use more than 10 items of criteria' and 'multiple nested smart groups is bad'. But when we ask for better querying ability we get 'Not Planned' with NO explanation why not. :(

@donmontalvo Which breakout session were those discussions, and do you think it was caught on video?

@cdenesha wrote:

I would expect Jamf to have really good mySQL architects and DBAs, yet I am unaware of a white paper providing guidance on this. I've heard generalities like 'don't use more than 10 items of criteria' and 'multiple nested smart groups is bad'.

DING DING DING! :)

We all like beer, right? We all want to have more than one beer, right? Well, unless you're hypoglycemic like me. :.(

If PersonA weighs N pounds and has X beers in Y minutes, it is reasonable to expect blood/alcohol level to get to Z. The only way to know if a threshold is met is to measure using a breathilizer.

If the breathilizer shows too high a value, you've exceeded the limit and you go to jail, lose your job, and end up in purgatory.

Because, as my esteemed colleague @SeanA would say, it's about metrics.

If JAMF provides a function, and we use it, and JSS slows down, and we are told we aren't doing anything wrong but the feature is like or is not like can cause performance issues, well, it's fair to ask.

Where are the metrics?

How many beers can we have before we can expect our performance to start to deteriorate? Beer is good, right? How many can we have before beer is not such a good thing?

Should we request a JSS breathilizer?

Jamf = bunch of really smart people. I think it's reasonable to expect some level of guidance in this topic. Please provide metrics, so we aren't flying blind.

Metrics will help us greatly. Even After Patch Managelent is ready for prime time. :) C'mon, one or two of @erin.miska's elves should be able to knock this out over a beer.

But just one beer. Because we don't want the quality of the article to deteriorate. Because. Metrics.

TIA,
Don

Just a comment on the metrics: they should be exposed via the GUI (or the API but GUI is preferable, perhaps Settings -> JSS Information), and not something we would have to run against the DB itself. Because many of us are hosted with no DB access.

@PeterClarke wrote:

Sometime there is no choice - if you want to get the criteria correct, sometimes you have to use the fuzzy 'like' match criteria. An Example would be Version Strings like: 16.0. ... ( 16.0, 16.0.0, 16.0.12 ) where it makes no sense to do 'an exact match'

There are choices, and it doesn't not make sense...just saying there are manageable, sustainable options such as leveraging major.minor for these kinds of scenaros. :)

version:

$ defaults read /Applications/Google Chrome.app/Contents/Info.plist CFBundleShortVersionString
61.0.3163.100

major.minor version:

$ defaults read /Applications/Google Chrome.app/Contents/Info.plist CFBundleShortVersionString | cut -f1-2 -d"."
61.0

For reference.