On 1/31/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
I'm looking to see how many other australians are interested inDjango, and also to get a list of people interested in some casualdjango work (if I get any) on the side.For the purposes of a census - I'm based in Perth.
I'm not really looking for c
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
Yeah, I think you're right, I'm just aware that other people might beusing the Q() syntax already and have some use cases for it that I'munaware of. I haven't used it myself, and working on the setsthemselves seems fine for me.
I have a need - or,
I'm looking to see how many other australians are interested in
Django, and also to get a list of people interested in some casual
django work (if I get any) on the side.
--
[EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909
If everything seems under control, you're not g
The magic-removal model unit tests do a lot of this:
list(Musician.objects.all())
That's because doing "Musician.objects.all()" at the Python
interactive interpreter doesn't actually display the data. Seems like
the list() is kind of clunky, and that QuerySet's __repr__() method
should displ
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 18:56, Luke Plant wrote:
> Actually, Q()s are immutable, so doing a deepcopy on their account
> was a complete mistake on my part. You don't have to copy them at
> all, which would make them rather nice to use performance-wise.
In which case, and assuming there aren't o
On Monday 30 January 2006 16:11, Adrian Holovaty wrote:
> ... I prefer avoiding copy.deepcopy() --
> which had been necessary in QuerySet._clone() due to the fact that we
> were using Q() instances. That meant each call to _clone() (for
> filter(), order_by(), etc.) was doing deepcopy(), which m
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
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> One thing - should _clone() actually do call
> 'self.__class__()' (or something like that), rather than QuerySet()?
> Otherwise you lose any subclass behaviour, which I don't think is
> desirable.
Good call -- yes, it should. Of course, if self.
Adrian wrote:
> It seemed a bit YAGNI to me, and I prefer avoiding copy.deepcopy() --
> which had been necessary in QuerySet._clone() due to the fact that we
> were using Q() instances. That meant each call to _clone() (for
> filter(), order_by(), etc.) was doing deepcopy(), which made me a bit
>
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> In the new descriptor syntax, are we going to allow Q() objects as
> positional arguments to the filter() method (and others)?
> [...]
> I mention this because I see you've changed core_filters back to a
> dictionary of lookup arguments, Adrian,
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
Robert Wittams wrote:
> Couldn't you just pass a model class or manager into your function that
> generates the appropriate queryset from that? Seems like an esoteric
> need anyway.
Yeah, I think you're right, I'm just aware that other people might be
using the Q() syntax already and have some u
Luke Plant wrote:
> In the new descriptor syntax, are we going to allow Q() objects as
> positional arguments to the filter() method (and others)? They seem
> like they could be a useful way of creating queries, although there is
> some duplication now that you can combine QuerySets directly. Ho
[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
In the new descriptor syntax, are we going to allow Q() objects as
positional arguments to the filter() method (and others)? They seem
like they could be a useful way of creating queries, although there is
some duplication now that you can combine QuerySets directly. However,
passing QuerySets a
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
>
19 matches
Mail list logo
