query.py refactoring by Malcolm: status?

[Adrian Holovaty]

Malcolm -- what's the status of the query.py refactoring you've been
working on? We have a bunch of features waiting for that refactoring,
including SQL aggregation support.

It'd be great to land that refactoring once and for all. I just did a
quick search of the django-developers archives and saw a reference to
the refactoring from last *September*! http://tinyurl.com/2sepls

(Not that I'm necessarily one to be in a position to "nag for lag," so
to speak, but I figured a little public prodding wouldn't hurt. :) )

If you're not able to devote time to it, I'm happy to take it over, as
long as you send a patch of your work so far. I'm keen on getting this
in.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[Malcolm Tredinnick]

On Mon, 2007-08-20 at 23:33 -0500, Adrian Holovaty wrote:
> Malcolm -- what's the status of the query.py refactoring you've been
> working on? We have a bunch of features waiting for that refactoring,
> including SQL aggregation support.
>
> It'd be great to land that refactoring once and for all. I just did a
> quick search of the django-developers archives and saw a reference to
> the refactoring from last *September*! http://tinyurl.com/2sepls
>
> (Not that I'm necessarily one to be in a position to "nag for lag," so
> to speak, but I figured a little public prodding wouldn't hurt. :) )

Yeah, you're right. I've been sucking a lot on this and keeping others
back. Everybody's been very restrained and understanding.

I need to stop changing my mind about what to do and stop getting
distracted by shiny objects like other bugs and finish this, or at least
get to the point that everybody can pitch in.

So, here's the plan: I'm going to go quiet on fixing other bugs and
possibly replying to non-essential Django e-mail for the rest of this
week and finish the code. I'm between jobs at the moment, so I can
devote time to it.

Thanks for the prod.

Cheers,
Malcolm

--
If Barbie is so popular, why do you have to buy her friends?
http://www.pointy-stick.com/blog/

[Justin Bronn]

I'm interested in the status too, and I'm willing to help out w/any
implementation. I've got a few feature requests for this refactor;
specifically, the possibility of mainlining several of the
modifications I've made in the GIS branch that assist in constructing
spatial SQL.

-Justin

[all.to....@googlemail.com]

Malcolm Tredinnick wrote:

> Yeah, you're right. I've been sucking a lot on this and keeping others
> back. Everybody's been very restrained and understanding.
>
> I need to stop changing my mind about what to do and stop getting
> distracted by shiny objects like other bugs and finish this, or at least
> get to the point that everybody can pitch in.
>
> So, here's the plan: I'm going to go quiet on fixing other bugs and
> possibly replying to non-essential Django e-mail for the rest of this
> week and finish the code. I'm between jobs at the moment, so I can
> devote time to it.

while your at it, i'm struggling with query stuff for a while now for
a
relative special model/field.

code:

https://dev.leipzig.freifunk.net/trac/browser/ffsomething/branches/generic/apps/management/models.py

What we need is a real IP Field, that can contain ip adresses (both
IPv4
and IPv6) as well as whole networks and does right ordering.
128 bit integer values are not available everywhere, so i decided to
split it into 4 32 bit integers.

As much as I read through the code, implementing this as a field is
not
supported, so I used a Model. However, implementing the model smoothly
isn't done easily. Currently is stuck transforming filter arguments:

>>> NetworkAddress.objects.filter(ip="192.168.1.1/32")
[<NetworkAddress: 192.168.1.1/32>]

however, ip does not exist and should be a simple to use alias for a
complex internal structure.

The problem is, that there is no hook or callback function in
parse_lookup and the only way I see currently is by tranforming every
Q
object in _filters.

But I'm absolutly unsure if I'm on the right track :)

kindly regards
daniel