Please don't change any code within django.db.models over the next few
days. Stimulated by ticket #2306, I took a look in there (particularly
the file query.py) and was a bit taken aback by how monstrous the code
has gotten. I'll be refactoring it over the next couple of days as I
get time...
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Hi Adrian,
Is this moratorium still in effect?
Ticket #2684 has patch that touches db.models.base and
db.models.options. It's not a particularly critical fix, so it can
wait if necessary. However, given that the lockout is two months old,
I thought I'd check just to make sure I didn't miss a memo somewhere
along the line.
Russ %-)
On Mon, 2006-09-11 at 20:34 +0800, Russell Keith-Magee wrote:
> On 7/8/06, Adrian Holovaty <holo...@gmail.com> wrote:
> >
> > To all Django committers --
> >
> > Please don't change any code within django.db.models over the next few
> > days. Stimulated by ticket #2306, I took a look in there (particularly
> > the file query.py) and was a bit taken aback by how monstrous the code
> > has gotten. I'll be refactoring it over the next couple of days as I
> > get time...
>
> Hi Adrian,
>
> Is this moratorium still in effect?
Regardless of the freeze status, the work itself (refactoring the query
generation) is blocking on me at the moment. I'm just re-emerging from
under a rock (work and illness) and getting that stuff finished is
number one priority. I'm taking some time off next week to work on this
sort of thing.
> Ticket #2684 has patch that touches db.models.base and
> db.models.options. It's not a particularly critical fix, so it can
> wait if necessary. However, given that the lockout is two months old,
> I thought I'd check just to make sure I didn't miss a memo somewhere
> along the line.
On the subject of that ticket in particular: I am suspicious about that
patch, reading it just now, although it will take a bit more thinking to
work out if my intuition is misleading me. Because of the model and app
caches in django.db.models.loading that are needed to have transparent
reverse relations, we have to be a bit careful about how early we run
through trying to work out all related objects -- if you do it at the
wrong moment, you don't get all models initialised properly and since we
only initialise the cache once, things go a bit strange. [I realise
that's the world's worst explanation of a potential problem, but I need
a whiteboard and hand waving or a lot more space to explain it in
detail; drop me a note if you really care.]
I'm not saying the patch is wrong, per se -- it may not be a problem at
all -- but just be careful about whether it's going to create problems
with the cache initialisation (have a look at
models.base.ModelBase.__new__ if you want to see the hoops we currently
jump through).
And anybody who wants to introduce a method called _init() in addition
to Python's existing __init__() is clearly a wanna-be Perl programmer
and should be viewed with caution in any case. :-)
Cheers,
Malcolm
> And anybody who wants to introduce a method called _init() in addition
> to Python's existing __init__() is clearly a wanna-be Perl programmer
> and should be viewed with caution in any case. :-)
:-)
Truth be told, I'm not particularly happy with the patch either. I
wasn't even particularly planning on commit it - it just raised the
issue of the current status of the freeze. I've clarified my comments
on the ticket to make sure it doesn't get applied (and to make sure
nobody thinks I'm a rogue Perl programmer :-)
The problem definitely exists (i.e., there is a use case that
demonstrates a problem). However, it's very low impact, and there is a
really easy workaround - you put in the extra import statement. I had
bit of a fiddle with ModelBase but I ended up with bootstrapping
problems. More thunking required...
Russ %-)