Hi Mads, Thanks for picking this up. I've been wondering if Window expressions would be possible, and what limitations we might have to make based on our ORM.
> 1. Since this is specific to postgres, I'm looking for a better place to put the actual Window-expression class, as well as axillary helpers (Order By, Partition and the frame). I would create a new file beside expressions.py called django/db/models/window.py. > 2. Tests, and if the initial test-cases seem fair? I took a small sample of test cases related to some made-up salaries in a few departments. Yes, it's a good start, but I haven't thoroughly reviewed them yet either. It'll be easier to do when there's a proper PR. > 3. The Order By-clause proposed in the initial code in the code only leaves room for one column (no expressions). Wouldn't the existing OrderBy type be sufficient? Really though, windowing should support a list of expressions (then call asc() or desc() on them). > 4. Would it be ok to add code for this in the base backend? Yes, if it makes the implementation nicer/easier for django and 3rd party backends. If having the code in the backend prevents *users* from creating their own windowing functions or modifying existing ones, then that's probably not ok. Django, backends, and users all need to be able to construct their own windowing expressions. You can certainly share code in the backend though, with things like PRECEDING ROW etc. > 5. Will a 2.0 release notes be introduced soon, The 1.11 alpha will be cut late January, which will trigger the creation of the 2.0 pages. Don't worry too much about release notes just yet. > I'm relatively new to Django internals (it's fun and educational hacking on them), and it took me some time to read through the code and documentation for the ORM, and there are many facets of it I can still understand. None of us understand all of the ORM, and we're more than happy to have more people helping out, so thanks! If you create a PR (even if it's not ready, just mark is [WIP] for Work In Progress) it'll be easier to comment on specific things within the code and see all of the commits tied together. You're also more likely to get feedback on a PR and some guidance there too. Cheers On Tuesday, 22 November 2016 23:19:10 UTC+11, Mads Jensen wrote: > > Hi, > > I got somewhat stuck on progress with this ticket, and as I'd like to > get it merged eventually (and avoid an abundant amount of fixes), I have > a few things I like a bit of input about. > > 1. Since this is specific to postgres, I'm looking for a better place to > put the actual Window-expression class, as well as axillary helpers > (Order By, Partition and the frame). > django/db/models/sql/expressions.sql may be one such place, but perhaps > introducing another file for this? Eventually, something like WITHIN > GROUP could be added, which shares some traits with window expressions. > This also goes the tests. > > 2. Tests, and if the initial test-cases seem fair? I took a small sample > of test cases related to some made-up salaries in a few departments. I > tried to introduce some wrapper to guard against testing functions that > aren't available (Oracle is the most complete in this sense, PostgreSQL > doesn't support all of the aggregate-functions, such as Variance). > > 3. The Order By-clause proposed in the initial code in the code only > leaves room for one column (no expressions). A regular query has > "add_ordering" to add more than one ordering-clause to a query, but this > just works for an ordering in SELECT, and I didn't spot anything that > could be used for this. Maybe abstracting the code from add_ordering so > it could be used also for something more? Something similar goes for > Partition By. Again, I'm sure it's a common use case to partition and > order by more than one expression. I currently commented out the > OrderByWrapper. > > 4. Would it be ok to add code for this in the base backend? I'm thinking > of constants for CURRENT ROW etc. which are shared among backends. I had > a look at SQLalchemy to see how things are arranged there, and what it > supports. SQLalchemy is feature-rich, but leaves out more > expressive-style ranges, and only supports unpreceding following/current > row, unbound following. I guess this is a reasonable limitation to make. > > 5. Will a 2.0 release notes be introduced soon, as I'm certain I won't > manage to make the final PR before the 1.11 feature freeze as it needs > to be finished, reviewed and merged. I started some time ago, and had it > lying around till I understood window functions better. > > As pointed out in #26608, I have some rough, drafty code that's quite > far from a PR. I'm more interested in input for the above. > > I'm relatively new to Django internals (it's fun and educational hacking > on them), and it took me some time to read through the code and > documentation for the ORM, and there are many facets of it I can still > understand. If someone is willing to guide me a bit, I'd be quite > helpful. Thank you. > -- > Med venlig hilsen / Kind regards, > Mads Jensen > > Saajan Fernandes: I think we forget things if there is nobody to > tell them. > -- The Lunchbox (2013) > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/77fc6c60-b146-4cb0-8047-20cfcb3b0892%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
