On 23/07/13 02:07, Curtis Maloney wrote:
Well, having started looking over the flup source, I can see a lot of
useful code to crib, as well as a few critical path bits that can be
optimised [without even reducing readability!]
So, if you feel like helping out with django-fastcgi ... I'm happy
Well, having started looking over the flup source, I can see a lot of
useful code to crib, as well as a few critical path bits that can be
optimised [without even reducing readability!]
So, if you feel like helping out with django-fastcgi ... I'm happy for the
help :)
--
Curtis
On 23 July
On Jul 23, 2013, at 3:17 AM, Aymeric Augustin
wrote:
> Either way the factory should receive the QuerySet in argument as well as any
> other parameters required to create the custom Manager appropriately.
I missed the "other parameters required" part.
I'm not a big fan of TIMTOWTDI so I don't think we should have both
`Manager.from_queryset()` and `QuerySet.as_manager()`.
The following commit moved all the logic that was on `QuerySet` to the
`Manager` class and implemented the `from_queryset()` API:
On 22 juil. 2013, at 17:31, Loic Bistuer wrote:
> The goal is to make it painfully easy to get a `Manager` from a custom
> `QuerySet` and for most cases, having the factory on `Manager` instead of
> `QuerySet` results in a more verbose syntax and requires an
On 22/07/13 10:00, Russell Keith-Magee wrote:
The hope is to start accelerating the release cycle slightly; however,
this also depends on someone actually doing the work :-)
Sounds good. I'd love to start helping with Django myself but I feel a
bit lost when it comes to useful things to do.
I would like to point out that using both a custom `Manager` *and* a custom
`QuerySet` is an edge case. After all, you can already do that if you want to.
The goal is to make it painfully easy to get a `Manager` from a custom
`QuerySet` and for most cases, having the factory on `Manager`
On Monday 22 July 2013 13:25:38 Anssi Kääriäinen wrote:
> On Monday, July 22, 2013 1:16:04 PM UTC+3, Loic Bistuer wrote:
> > On Jul 22, 2013, at 4:38 PM, Chris Wilson
> >
> >
> > wrote:
> > > I think that's very true. How about this?
> > >
> > >> class
On 12 juil. 2013, at 22:47, Tim Graham wrote:
> formset.save(commit=False) on ModelFormSets currently deletes any objects
> marked for deletion which seems like a bug to me, since I wouldn't expect any
> data changing operations when using commit=False. I put together a
On 22 juil. 2013, at 12:16, Loic Bistuer wrote:
> That was my original proposal; the first 20 comments on the ticket and one
> nearly complete implementation are based on this idea.
Oh, sorry. I dived into the pull request without reading the ticket first.
I'm
On Monday, July 22, 2013 1:16:04 PM UTC+3, Loic Bistuer wrote:
>
> On Jul 22, 2013, at 4:38 PM, Chris Wilson
> wrote:
>
> > I think that's very true. How about this?
> >
> >> class MyQuerySet(models.QuerySet):
> >> def published(self):
> >>
On Jul 22, 2013, at 4:38 PM, Chris Wilson wrote:
> I think that's very true. How about this?
>
>> class MyQuerySet(models.QuerySet):
>> def published(self):
>> return self.filter(published_date__lte=now())
>>
>> class MyModel(models.Model):
> To anyone else reading this thread who is still wanting FastCGI I am willing
> to help with a third party solution if something is going to come together.
> Based on the normal Django release cycle I'd expect 1.7 to be out in either
> Q4 this year or Q1 next year so something needs to be done
On Mon, 22 Jul 2013, Michal Petrucha wrote:
I have some awesome news today. At long last I managed to finally get
the refactor of ForeignKey to pass the entire test suite.
That is awesome news! Well done Michal! I am really looking forward to
having this feature available in Django.
The idea of `QuerySet .as_manager()` sounded sane to me at first—especially in
the light of the failure of various other attempts—but it creates a circular
dependency between `Manager` and `QuerySet`. Creating the `Manager` class now
requires the `QuerySet` class, and `QuerySet` needs a
On Mon, Jul 22, 2013 at 4:48 PM, Some Developer
wrote:
> On 22/07/13 05:47, Russell Keith-Magee wrote:
>
>> Based on the feedback from this thread (and the fact that multiple core
>> devs, including a BDFL have weighed in), I think it's safe to say that
>> the decision
On 22/07/13 05:47, Russell Keith-Magee wrote:
Based on the feedback from this thread (and the fact that multiple core
devs, including a BDFL have weighed in), I think it's safe to say that
the decision has been made. The only question at this point is how long
it takes before someone commits the
Ticket #20625 deals with the problem of writing custom QuerySet methods.
The problem is that one needs to write some boilerplate code to have
methods available on both the Manager and the QuerySet. The ticket has a
patch for having custom QuerySet methods automatically available on the
model's
I updated the PR to do away with the public `clone()` method.
As long as we have a long-term goal for a `QuerySet.clone()` method, I'm happy.
If we plan on changing the cloning behavior, now is effectively a bad time to
introduce it.
--
Loic
On Jul 22, 2013, at 2:45 PM, Anssi Kääriäinen
On Sunday, July 21, 2013 9:53:36 PM UTC+3, Loic Bistuer wrote:
>
> Explicit is better than implicit and `all()` is more a `Manager` concept
> than a `QuerySet` one.
>
> IMO `QuerySet.all()` should only be used when API parity with `Manager` is
> needed.
>
> Internally `QuerySet` uses
20 matches
Mail list logo