Fork me on GitHub

At present, Afterburner takes as input SQL queries in the form of what we refer to as "fluent" SQL, based on a method-chaining notation. This was inspired by squel.js and we took this route to save ourselves from having to write yet-another SQL parser. There is a straightforward mapping from SQL queries to our "fluent" SQL representation, so this is simply syntactic sugar. However, biting the bullet and actually writing a SQL parser is part of our roadmap.

Here are some examples:

SQL
SELECT name, salary 
FROM employees 
WHERE salary > 100000 
ORDER BY salary
LIMIT 10;
SELECT d.name, AVG(e.salary)
FROM employees e
JOIN departments d ON e.deptId = d.id
WHERE e.location = 'Waterloo'
GROUP BY d.name;
"Fluent" SQL
abdb.select().from('employees')
  .field('name','salary')
  .where(_gt('salary',100000))
  .order('salary')
  .limit(10)
abdb.select().from('employees')
 .join('departments').on('employees.deptId', 'departments.id')
 .field('departments.name', _avg('employees.salary'))
 .where(_eq('location', 'Waterloo')
 .group('departments.name');

Comparisons

Other points of comparison with Afterburner: