Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Implement window function support

See original GitHub issue

We should create derivates of the standard aggregate functions e.g. count -> count_window that support the FILTER and OVER clauses. The FILTER clause will always have to be rendered by using a CASE WHEN statement in the function. The OVER clause should support PARTITION, ORDER BY and ROWS/RANGE clauses and also accept a named window. In order to support a named window, we would first have to add support for adding windows to a query. I propose to add a method to start a window builder on a QueryBuilder e.g. window(String name). There you can define partitions, orderings and framing. Note that windows defined in a subquery have precedence for that subquery. So windows can shadow same named windows from the parent query.

Note that since there is semantically no difference between reusing a window name or inlining the window clause, we will always inline the contents to the window functions as this is easier to implement because it doesn’t require SQL replacements.

Here are some links to documentation about this

The following functions would be affected by this

  • AVG
  • MIN
  • MAX
  • SUM
  • EVERY?

Also see the following reference:

While doing that we could also look into adding some window only functions:

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:2
  • Comments:5 (2 by maintainers)

github_iconTop GitHub Comments

jwgmeligmeylingcommented, Aug 15, 2018

Ok! Then we’re on the same page. I’ll keep needing Window functions here and there, so I am considering to have a look at it in the next few days.

beikovcommented, Aug 15, 2018

IMO, the syntax support for expression in the Blaze-Persistence APIs should be as close to SQL as possible i.e. allow to do"avg(salary) over (partition by depname order by depname asc)"). The translation to JPQL could be like FUNCTION('AVG', salary, 'OVER', 'PARTITION BY', depname, 'ORDER BY', depname, 'ASC'). The JPQLFunction implementation then renders that to SQL. Let’s ignore uses when the DBMS does not support it for now to avoid having to detect the DBMS versions.

Read more comments on GitHub >

github_iconTop Results From Across the Web

SQL Window Functions | Advanced SQL - Mode Analytics
This lesson of the SQL tutorial for data analysis covers SQL windowing functions such as ROW_NUMBER(), NTILE, LAG, and LEAD.
Read more >
Implementing window functions in go-mysql-server - DoltHub
The simplest way to think of a window function is that it's like a group-by aggregate function, but it gets a value for...
Read more >
Database Products with Window Functions Support
Detailed list of all database products with native support for Window Functions, including the OVER and WINDOW clauses, or analytic and ...
Read more >
How to use Window functions in SQL Server - SQLShack
This article explains the use of Aggregate, Raking and Value Windows Functions in SQL Server.
Read more >
Window Functions - SQLite
A window function is an SQL function where the input values are taken from a "window" of one or more rows in the...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found