GSOC Idea for window function expression

Hello everyone,
My name is Manav. I’m a Computer Science and Engineering junior at Dr. A.P.J. Abdul Kalam Technical University in India.
I have solved many issues on trac (listed here).

These days I am trying to figure out the problem with window function expression in Django. #26608 introduces support for window function in Django using window function expression. But there is a problem with the newly introduced expression that is it is not filterable. Apart from this, there are a lot of issues with the implementation like #32297, #32277.
After some research, I came us with some basic approaches like a separate QueryWrapper class which may constitute success for filtering the querysets.

I was thinking to take this idea into consideration for my GSoC proposal 2021. I analyzed the code for the window expression and found that interesting. I would like to improve all such loopholes in the implementation.

Suggestions from expert fellows are most welcome. I need some guidance on how can I implement the same. And last but not least is it a good idea to consider it as a GSoC proposal?

Hi @manav014 — thanks for the post — let me ping @felixxm to see if he’s able to offer some insights here.

Thank You @carltongibson for your reply.
I researched the issue and found that this won’t be much beneficial for the GSoC perspective as this is a feature that would be used by a less number of developers. So I started working on the Migrations Framework slowdown problem.
I will solve this(Window function) problem after successfully speeding up the Migrations by making SchemaEditor work with ModelState in spite of Models.

1 Like

I have noted all the key points related to window function which may help window functions with filtration like using Sub Queries. I will work on them as soon as I will solve #29898 (Adapt schema editors to operate from model states instead of fake rendered models) – Django .
Till then if anyone wants to work this out, then I would be glad to help.

1 Like