On Sun, May 12, 2013 at 9:36 AM, Anssi Kääriäinen
wrote:
> On 12 touko, 02:55, Russell Keith-Magee
> wrote:
> > To that end - I want to make sure that we're clear about what we're
> talking
> > about here.
> >
> > What is on the table is essentially adding a refresh() call on an object
> > instan
On Sun, May 12, 2013 at 9:02 AM, Alex Ogier wrote:
> On Sat, May 11, 2013 at 7:55 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>> I'm sure I understand this argument. Python objects are passed around by
>> reference, not by value, so if you've passed in a Django object deep into
On Mon, May 13, 2013 at 2:03 AM, Jason Reethisma wrote:
> @Russell
>
> "can't compel anyone to do anything"... you can compel people to NOT do
> something, such as, "don't close a ticket as won't-fix without giving a
> detailed explanation of why it should be closed".
>
> Saying that people cannot
On 05/11/2013 06:01 PM, Shai Berger wrote:
> On Sunday 12 May 2013, Łukasz Rekucki wrote:
>> Hi,
>>
>> On 11 May 2013 22:58, Shai Berger wrote:
>>> In
>>> other communities, I have usually seen "needsinfo" as a ticket state,
>>> rather
>>> than a reason for closing; such tickets are then closed la
On Sun, 2013-05-12 at 11:03 -0700, Jason Reethisma wrote:
> @Russell
>
> "can't compel anyone to do anything"... you can compel people to NOT do
> something, such as, "don't close a ticket as won't-fix without giving a
> detailed explanation of why it should be closed".
>
> Saying that people
In MyModelB, at least, the subclass' refresh method would win, since it's the
subclass.
I'm not sure about MyModelA, since I am not quite sure how the metaclass'
processing would intersect.
That said, if there's demand for the feature, it's probably worth this cost.
(Bias: I would use it if it
On 2013-05-11 18:36, Anssi Kääriäinen wrote:
> On 12 touko, 02:55, Russell Keith-Magee
> > What is on the table is essentially adding a refresh() call on an
> > object instance that is an API analog of
> > ".get(id=self.id)"
I guess my minor quibble is about the name itself and possible
clashes w
On Sat, May 11, 2013 at 6:36 PM, Anssi Kääriäinen
wrote:
> Does the proposal look acceptable?
Yes. +1 from me.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send a
@Russell
"can't compel anyone to do anything"... you can compel people to NOT do
something, such as, "don't close a ticket as won't-fix without giving a
detailed explanation of why it should be closed".
Saying that people cannot be compelled is an excuse to not take action.
Ignoring the 3 out
On 12 touko, 19:15, Aymeric Augustin
wrote:
> > The refresh() method accepts *args, so that one can specify which
> > fields to reload. This is useful so that deferred attribute loading
> > can use refresh(), and by overriding refresh() it will be possible to
> > customize how deferred loading hap
On Sunday 12 May 2013, Aymeric Augustin wrote:
> On 12 mai 2013, at 10:24, Shai Berger wrote:
> > Relatedly, we now cache back-references of 1-to-1 relations on the
> > instance
>
> Django has cached them for a long time. It's just a bit more efficient and
> deterministic as of Django 1.5. :)
>
On 12 mai 2013, at 10:24, Shai Berger wrote:
> Relatedly, we now cache back-references of 1-to-1 relations on the instance
Django has cached them for a long time. It's just a bit more efficient and
deterministic as of Django 1.5. :)
> those should probably be updated (on remote objects!) too, o
On 12 mai 2013, at 03:36, Anssi Kääriäinen wrote:
> Concrete API proposal: Model.refresh() reloads all non-deferred local
> field values (that is, all fields in the current model which have a
> database column). In addition refresh() will make sure that cached
> values dependent of the reloaded v
Hi,
There's one minor issue that I'm not entirely clear of with this proposal:
On Sunday 12 May 2013, Anssi Kääriäinen wrote:
>
> Concrete API proposal: Model.refresh() reloads all non-deferred local
> field values (that is, all fields in the current model which have a
> database column). In add
Right now that ticket's just got a cautious +0 against it.
I still think this would be a small step in the right direction of
presenting a slightly simpler GCBV API, but unless there's any further
support I'm inclined to give the ticket a few more days and then close it.
On Thursday, 2 May 2013
15 matches
Mail list logo
