On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> I attempted something like this first time (I think you mean it would
> return a version with caching *enabled* each time, right?), but removed
> it again. I wasn't sure how it would interact with things like
> _default_manager, and also if you
On Monday 30 January 2006 16:04, Brant Harris wrote:
> That said... Person.objects could be a property that returns the
> Manager/Query. In this way you could send a cacheless version of it
> every time it is called, and would work for your first bit of code,
> as desired.
I attempted somethin
Although, I think it'd be great to have it as propsed, at some point
the OO of your ORM needs to make consessions to the SQL of your ORM.
Which goes back to my earlier proposal.
That said... Person.objects could be a property that returns the
Manager/Query. In this way you could send a cachele
[EMAIL PROTECTED] wrote:
> Adrian Holovaty wrote:
>
>
>>This comes back to the Person.objects.all() thing that I'd mentioned
>>earlier. With all(), there's no strange special-case behavior.
>>Person.objects.all() would return a cache-filled object, and there
>>wouldn't be a need for a QuerySet t
Amit Upadhyay wrote:
> Have not been following the discussion very closely, but why not have a
> parameter use_cache (defaulting to True) in the get_list and making it
> completely explicit. Sometimes I like the conveniece of not storing
> something in a variable, like from within a template, an
On 1/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Presumably this needs the same behaviour as a Manager i.e. doesn'tcache. So the the filter method needs to return a non-caching
QuerySet. To get a caching version, you would have to do .all(), soyou would have to do this everytime you actua
Adrian Holovaty wrote:
> This comes back to the Person.objects.all() thing that I'd mentioned
> earlier. With all(), there's no strange special-case behavior.
> Person.objects.all() would return a cache-filled object, and there
> wouldn't be a need for a QuerySet to know whether it could accept
>
Adrian Holovaty wrote:
This would further simplify things by making a Manager's methods
*return* QuerySets instead of having a Manager *be* a QuerySet. The
downside is it's slightly more typing to do Person.objects.all() than
Person.objects -- but that's the only downside I see. Thoughts?
.a
On 1/28/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> As Robert pointed out before, you usually don't have to worry about
> resetting the cache, since the objects will get GC after the template
> and views stop using them. However, the Article.objects manager is
> special, since it is rooted in a c
> We had this discussion a while back; the goal is to separate
> "instance-level" functionality from "table-level" functionality.
> Anything that doesn't explicitly act on a model instance goes in the
> manager. With that in mind, I'm not sure having Manager subclass
> QuerySet (and making it a de
On 1/28/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > My mistake -- get_pub_date_list() wasn't the best example. Better
> > examples would be completely custom manager methods, such as
> > create_user() and and make_random_password() in
> > django.contrib.auth.models.UserManager.
>
> Is t
On Saturday 28 January 2006 14:23, Robert Wittams wrote:
> Hm, that does make sense. +1 .
Except this sentence, which I never managed to finish:
> > That would mean that if the manager, for instance, happened to be
> > ordered, you would lose ordering if you did an 'or' query, even
> > between.
Luke Plant wrote:
>>hugo and I talked on IRC about this, probably a couple of months ago
>>now. The best we could come up with for the | case was "undefined" -
>>probably remove the ordering clause completely.
>
>
> That would mean that if the manager, for instance, happened to be
> ordered, y
OK, more holes in the proposal. Everything that used to be kwarg to
Manager().get_list() (or other methods), now has to alter the state of
the QuerySet, otherwise caching won't work. So we have the following
that still need sorting out:
select_related
limit
offset
params
select
where
tables
> hugo and I talked on IRC about this, probably a couple of months ago
> now. The best we could come up with for the | case was "undefined" -
> probably remove the ordering clause completely.
That would mean that if the manager, for instance, happened to be
ordered, you would lose ordering if yo
Luke Plant wrote:
> Some more implementation questions:
>
> Presumably:
>
> Article.objects.order_by(('title',)).order_by(('something_else',))
> ==
> Article.objects.order_by(('something_else',))
>
> so that you can override an ordering (I can't see many use cases for the
> alternative i.e. cu
Some more implementation questions:
Presumably:
Article.objects.order_by(('title',)).order_by(('something_else',))
==
Article.objects.order_by(('something_else',))
so that you can override an ordering (I can't see many use cases for the
alternative i.e. cumulative ordering)
But what about thes
Adrian Holovaty wrote:
> I've implemented the very first bit of descriptor fields -- the bit
> that does poll.choice_set instead of poll.get_choice_list().
>
> http://code.djangoproject.com/changeset/2141
>
> Just before that, I'd added a core_filters attribute to Managers,
> which, if set, is a
On Saturday 28 January 2006 00:34, Adrian Holovaty wrote:
> I've implemented the very first bit of descriptor fields -- the bit
> that does poll.choice_set instead of poll.get_choice_list().
I'm up for doing some work on this, and have some time at the moment,
even if it's just converting all the
On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/27/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > > An implementation question, though: If foo.objects is a Manager
> > > instance, and accessing foo.objects returns a
On 1/27/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > An implementation question, though: If foo.objects is a Manager
> > instance, and accessing foo.objects returns a QuerySet instance, how
> > would one access the other manager me
On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> An implementation question, though: If foo.objects is a Manager
> instance, and accessing foo.objects returns a QuerySet instance, how
> would one access the other manager methods, such as
> foo.objects.get_pub_date_list(), etc.?
Isn't ge
I've implemented the very first bit of descriptor fields -- the bit
that does poll.choice_set instead of poll.get_choice_list().
http://code.djangoproject.com/changeset/2141
Just before that, I'd added a core_filters attribute to Managers,
which, if set, is applied to every data-access query for
23 matches
Mail list logo
