Misspell a field name in GlideRecord and it does not complain - it ignores the condition and returns every record in the table. GlideQuery fails instead. That single difference is the reason to care about it, and everything below follows from it.
GlideQuery is a server-side API for CRUD operations, available from Orlando onwards. It is a wrapper over GlideRecord with a fluent, chainable interface, and it is 100% JavaScript. It also replaces GlideAggregate in some cases, particularly for counting records.
What it is built on
The API consists of two global script includes: GlideQuery, which you can read, and GlideQueryEvaluator, which is protected and you cannot. It uses GlideRecord underneath, presumably inside the evaluator.
So it does not replace GlideRecord. It is an additional layer on top of it, and the benefit is a smaller chance of getting a query wrong.
Three guiding principles
- Fail fast - a bad field name is an error, not a silently broader query.
- Be JavaScript - it behaves like a normal JavaScript API rather than a platform-specific one.
- Expressive - the query reads as a chain, so the intent is visible in the shape of the code.
What you get in practice
- Field checking - the query is validated before it executes.
- Failing fast - mistakes surface at the point they are made.
- A shorter feedback loop - you find out in development rather than from a report that quietly returned too much.
- Performance - the validation runs before the query, so a malformed one never reaches the database.
On the performance point, be careful what you conclude. GlideQuery validates priority, short_description and the rest of the fields you name before executing, which avoids the cost of a wrong query - but it is still GlideRecord underneath. Treat it as a correctness feature that avoids waste, not as a faster engine.
Installing it without Software Asset Management Pro
The plugin can be installed from a background script:
var plugins = [];
plugins.push('com.sn_glidequery');
var main = new GlideMultiPluginManagerWorker();
main.setPluginIds(plugins);
main.setProgressName("Plugin Installer");
main.setBackground(true);
main.start();Reading multiple rows
new GlideQuery('task')
.where('priority', 1)
.select('short_description', 'opened_at')
.forEach(function (task) {
gs.info('Task "' + task.short_description + '" was opened at ' + task.opened_at);
});Using select and stream
new GlideQuery('sys_user')
.select('first_name')
.forEach(function (user) {
gs.info(user.first_name);
});Reading a single record
Three ways to ask for one record, differing in what happens when it is not there:
// Find the user if they exist, otherwise return one with first_name 'Nobody'
var user = new GlideQuery('sys_user')
.where('last_name', 'Luddy')
.selectOne('first_name')
.orElse({ first_name: 'Nobody' });
// Find the user, otherwise throw an Error that they could not be found
var user = new GlideQuery('sys_user')
.where('last_name', 'Luddy')
.selectOne('first_name')
.get(); // this method can throw if no record is found
// Does a given user exist? Assign a boolean to userExists
var userExists = new GlideQuery('sys_user')
.where('last_name', 'Luddy')
.selectOne('first_name')
.isPresent();In a scoped application, reach it through the global scope:
new global.GlideQuery('sys_user')Is GlideRecord going away?
No. GlideQuery is a layer over it, not a replacement, and there is no sign of GlideRecord being deprecated. The honest summary is narrower than either side of that argument: GlideQuery catches a class of mistake that GlideRecord swallows, and it reads better while doing it. On a codebase where a mistyped field name has ever quietly returned the whole table, that is worth the migration cost. On one where it has not, it is a preference.
The full method list is in ServiceNow's GlideQuery API reference.
If you are weighing a move to GlideQuery across an existing instance, or untangling queries that return more than they should, tell us what you are running.