status update
Luke Plant
- add tests and implementation for o2m .clear() and .remove() methods
- work out what these methods (clear and remove) should return, if
anything e.g. True if something was changed. This is especially
relevant for the manipulators. I haven't changed the instances of
'set_%s' in that code since they need a return value that says if
anything was changed, which can no longer be supplied since the
operation would now be a .clear() followed by .add(). Also, it might
need rethinking since the .add() call is significantly more expensive
now, unless you create dummy objects with just the pk set and pass them
into .add(). Sorry if that's a jumble, it might make sense if you look
at db/models/manipulators.py and db/models/fields/related.py
- thrashing out some issues:
(1) due to the manager/queryset relationship, the methods that change
data don't exist on the QuerySets. So, if you do:
reporter.article_set.filter(pubdate_lt=datetime(2000, 1, 1)).clear()
it won't remove a subset of that reporter's articles, it will throw an
exception. Is this desired behaviour? It doesn't bother me at all, I
just thought I'd highlight a consequence of having managers as a proxy
for QuerySets, which I think was done mainly due to the caching issue.
(2) Slice notation on QuerySets: it currently returns a list, but it
might be good if it returned a QuerySet. I'm thinking especially of
the generic views, where you might want to pass in a QuerySet that has
a limited number of rows (e.g. Top 10 News items as part of the
extra_context), and define this in the url conf. It shouldn't be hard
to make this change, the only thing needed will be some extra checking
when doing methods like .filter(), order_by() and combining sets. Once
the limit or offset have been set, you would have to disallow methods
that change which rows would be returned i.e. changes to the WHERE or
ORDER BY clauses.
- scouring the code for instances of old style syntax.
- 4 failing tests - one2one and manipulators stuff.
- management.py - I think it requires a fair bit of love.
- Descriptor syntax for other fields: according to the proposal,
article.reporter.id wouldn't do a db lookup, which would require some
more descriptor stuff and lazy loading etc. I think Adrian has been
working on this.
Those things aside, I don't think there is much to do with 'Descriptor
fields' changes (though the last one might be a lot of work).
I am unfortunately very busy now until the end of this month (possibly
longer), and it is very unlikely that I'll be able to finish off any of
these things, so I thought I'd brain dump these thoughts now -- hope
you can make some sense of them :-)
Regards,
Luke
--
I teleported home one night
With Ron and Sid and Meg,
Ron stole Meggie's heart away
And I got Sidney's leg
(THHGTTG)
Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
Luke Plant
> Some things that are still to be done in the current batch of
> changes:
I forgot to mention the generic views - I converted the 'list_detail'
ones but none of the others.
Luke Plant
> - thrashing out some issues:
Here is another thing. I don't like that you currently have to do this
in templates:
{% for foo in bar.foo_set.all %}
...
{% endfor %}
instead of
{% for foo in bar.foo_set %}
...
{% endfor %}
I did have a patch at one point that made RelatedManager a subclass of
firstly QuerySet, secondly Manager (which was the right way around for
the __init__ etc to work). However I had problems with it - I think
mainly to do with .add() (and now the rest of them - clear and remove).
These methods would need to clear out the cache, and it wasn't obvious
how to do this. But I don't think those problems are insurmountable,
and I think it could make things a lot nicer. A complication is then
that a .filter() call would (or at least could) produce a clone of a
RelatedManager, and so it would still have .clear(), .add() methods,
which would then be impossible to implement correctly, so you would
have to remove them somehow or stop the ._clone() method from creating
a new RelatedManager.
Regards,
Luke
--
"I think you ought to know I'm feeling very depressed." (Marvin the
paranoid android)
Luke Plant
> I did have a patch at one point that made RelatedManager a subclass
> of firstly QuerySet, secondly Manager (which was the right way around
> for the __init__ etc to work). However I had problems with it - I
> think mainly to do with .add() (and now the rest of them - clear and
> remove). These methods would need to clear out the cache, and it
> wasn't obvious how to do this.
This is rubbish of course - it's easy for a subclass of QuerySet to
clear out the cache. I think I was confused by the Manager.add()
method.
This is turning into yet another thread where I ramble on to myself.
Not good.