A month ago I wrote about GlideQuery, asking "... is GlideRecord going away? No. I don't think so. "

Well, I need to revise my thoughts on this. Before I go into why, lets first link to the sources and you can watch the 20+ minute video of the genius (Peter Bell) behind GlideQuery.

Link to that is here: GlideQuery: A modern upgrade to GlideRecord

Okay. Now that is out of the way lets talk about some of the major points here so if we lose the video we still have this somewhere since as of right now this is not documented anywhere.

What does GlideQuery do that GlideRecord fails?

GlideQuery is a server-side api for querying, updating, and deleting data. It's in Orlando, and Paris. Behind the scenes it uses GlideRecord but with smart defaults that often will cause generally problems.

This api follows three guiding principals;

  • Fail Fast
  • Be JavaScript
  • Expressive

Here's some considerations;

  • Performance

Failing Fast

Improving the feedback loop

Field Checking

Here's a GlideRecord script with a problem
By default if a field name is wrong in GlideRecord, it queries everything.

In GlideQuery, this will fail and not execute on error.

GlideRecord Example GlideQuery Example

Choice checking

Here's another example where unless you check your code you may miss it. This is because it returns no results.

If the api said, hey that value is not valid, that could help you faster.

GlideRecord Example GlideQuery Example

Type checking

Travis Toulson wrote a whole post about Is GlideRecord GetValue the king of the string... It's great but this SOLVES that whole issue.

GlideRecord Example GlideQuery Example

Be JavaScript

Isolation from Java

GlideQuery should behave you expect a regular JavaScript should behave.

Type assumptions in are a real headache in ServiceNow with GlideRecord. It seems you get back a string type when you should get a number type.

GlideRecord Example GlideQuery Example


GlideRecord Example GlideQuery Example

Complex Queries should work how you expect

Queries that use both "AND" and "OR" logic. How is this evaluated?

GlideRecord Example GlideQuery Example

In SQL "AND" has priority over "OR". In GlideRecord, "OR" has priority over "AND" and this causes problems. In GlideQuery they solve this by being allowing nested GlideQuery methods.


Do more with less

Returning a Stream or Optional

When reading data with GlideQuery there are two classes used; Stream and Optional

Stream Optional
Used for reading records Used for reading a single record
Returned by select(1) "Empty" if a record isn't found by a query
Lazily evaluated Returned by selectOne(), insert(), and update()
Common Stream methods:
- map
- flatMap
- forEach
- reduce
- some
- any
Common Optional methods:
- get [throws if empty]
- map
- isEmpty
- isPresent
- ifPresent
- orElse







Field Flags

This is important for currency and display values.

Flags mentioned $DISPLAY and $CURRENCY_CODE


With business rules disabled here's how GlideQuery stacks up to GlideRecord.

Method GlideRecord GlideQuery
Insert 100 records 829 ms median 850 ms median (+2.5%)
Reading 1 record 2ms median 3ms median (+1 ms)
Reading 1,000 record 86.5 ms median 90.5 ms median (+4.62%)
Reading 10,000 record 842.5 ms median 890 ms median (+5.64%)

It's important to note that GlideQuery avoids common performance mistakes.

Current Limitations and Future work

  • Scoped table permission checking
  • Allow opting out of field/choice checking
  • Better join support
  • Field casting
  • Parsing encoded queries