Draft DEP: ORM expressions API changes

[Anssi Kääriäinen]

I have written a DEP about planned ORM expressions API changes. See
https://github.com/django/deps/pull/5 for the proposed DEP.

The plan is to throw away sql.expressions.SQLEvaluator, rewrite how
expressions work and make aggregates subclasses of expressions.

Short summary of the goals and problems of the DEP:
- The aim is to allow writing custom expressions through public API,
allow usage of F() expressions in annotations and doing arithmetic
operations on aggregates
- Simplify coding of the ORM
- The DEP is based on work done by Josh Smeaton in pull request
https://github.com/django/django/pull/2496. While the patch will solve
multiple issues, the main ticket tracking these changes is #14030.
- The main problem is backwards compatibility - writing custom
expressions or non-SQL backends requires usage of private APIs. The DEP
aims to change those private APIs.

I am planning to actually include the DEP as a draft in the django/deps
repository once the most problematic pats of the draft have been
rewritten. Once committed into the django/deps repository collaboration
on the DEP will be much easier.

As there isn't currently any process for actually accepting DEPs it
might be possible that we need to move on with Josh Smeaton's work
before the DEP is formally accepted. Of course, I hope that we get the
DEP process going on, so we can first accept the DEP, then commit the
actual implementation.

Comments on the ORM epressions API changes should go to the pull request
for now. Comments on the DEP process itself are welcome here.

- Anssi

[Anssi Kääriäinen]

I plan to push the DEP as draft to the django/deps repository. The DEP
will be DEP number 2.

DEP 2 will need to be accepted or rejected eventually. Before that it
doesn't have any official status.

I am planning to do the push as this way it is easier to work on it
collaboratively. There is a lot of work to do, from the actual content
to language and formatting improvements. As this is one of the first
DEPs we will need to also decide what structure we want to have in the
DEP.

Any objections to pushing the DEP as draft to django/deps repository?

- Anssi

[Russell Keith-Magee]

Hi Anssi,

My only concern about pushing the DEP and formally numbering it is that we haven't fully worked out what our DEP process *is* yet. I'm still recovering from DjangoCon US jet lag, but once that has worn off, I've got some ideas about how we can use the DEP process and the technical board to formally engage members of the community. I don't doubt that your DEP will be the first one that will get handled by any formal process, but I'd like to have a brief discussion about that process first.

From a purely bike shedding / OCD angle, I'd also like to keep the low numbers for procedural reps (analogs of Python's DEP 8); so I'd prefer to keep the technical DEPs starting from 100. But that's just me :-)

Russ %-)

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1410347119.11410.791.camel%40TTY32.

For more options, visit https://groups.google.com/d/optout.

[Anssi Kääriäinen]

On Thu, 2014-09-11 at 06:33 +0800, Russell Keith-Magee wrote:


> My only concern about pushing the DEP and formally numbering it is
> that we haven't fully worked out what our DEP process *is* yet. I'm
> still recovering from DjangoCon US jet lag, but once that has worn
> off, I've got some ideas about how we can use the DEP process and the
> technical board to formally engage members of the community. I don't
> doubt that your DEP will be the first one that will get handled by any
> formal process, but I'd like to have a brief discussion about that
> process first.

I was mistaken about the requirement to give a number to draft DEPs. We
can include DEPs into deps/drafts/ folder without numbering the DEP.
[https://github.com/django/deps/blob/master/drafts/README.rst]

I am going to work the DEP into acceptable format no matter what happens
to the DEP process. I believe DEP format will make it easier to see what
exactly is proposed and why (as opposed to mailing list threads where it
can be hard to follow what exactly is proposed).

It might be necessary to continue without formal acceptance of the DEP.
Of course, I don't plan to skip the DEP process, I am just saying that I
am not going to wait indefinitely for the process to arrive.

There have been other DEP proposals that have been waiting far longer
than my DEP. I hope that ORM expressions DEP isn't fast-tracked just
because it is a DEP from a core member.

>
> From a purely bike shedding / OCD angle, I'd also like to keep the low
> numbers for procedural reps (analogs of Python's DEP 8); so I'd prefer
> to keep the technical DEPs starting from 100. But that's just me :-)

Luckily there is no need to decide this yet :)

- Anssi