On 14 touko, 18:07, Tim Chase wrote:
> On 2013-05-14 10:43, Alex Ogier wrote:
>
> > What happens in the following case?
>
> > a = A(dict_field={"hello": "world"})
> > d = a.dict_field
> > a.save()
> > a.refresh()
> > d["hello"] = "planet" # does this mutate a.dict_field? does the
> > answer cha
On 2013-05-14 10:43, Alex Ogier wrote:
> What happens in the following case?
>
> a = A(dict_field={"hello": "world"})
> d = a.dict_field
> a.save()
> a.refresh()
> d["hello"] = "planet"# does this mutate a.dict_field? does the
> answer change if somebody changed the database in between saving
On Tue, May 14, 2013 at 7:38 AM, Shai Berger wrote:
> On Tuesday 14 May 2013, Alex Ogier wrote:
> >
> > It's a totally new behavior that has
> > plenty of corner cases such as foreign keys, and especially
> OneToOneFields.
> >
> Another one is initializers: get() or any other method of fetching
On Tuesday 14 May 2013, Alex Ogier wrote:
>
> It's a totally new behavior that has
> plenty of corner cases such as foreign keys, and especially OneToOneFields.
>
Another one is initializers: get() or any other method of fetching an object
from the database will call __init__() with the fields
On Tue, May 14, 2013 at 12:09 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> As far as I can make out, that's exactly the same use case -- you're just
> making the example a little bit more explicit regarding the fact that 'a'
> is an object referred to by reference, so if 'a' is upda
On Sun, May 12, 2013 at 8:10 AM, Andrew Ingram wrote:
> On 12 May 2013, at 00:55, Russell Keith-Magee
> 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
> another library, that library w
On Sun, May 12, 2013 at 3:05 PM, Chris Wilson wrote:
> Hi all,
>
>
> On Sun, 12 May 2013, Shai Berger wrote:
>
> those should probably be updated (on remote objects!) too, or else some
serious inconsistencies may be created (when the _id field changes, that
is).
>>>
>> aa= A.objec
Hi all,
On Sun, 12 May 2013, Shai Berger wrote:
those should probably be updated (on remote objects!) too, or else
some serious inconsistencies may be created (when the _id field
changes, that is).
aa= A.objects.get(...)
bb= aa.b
(some other operation, changing aa.b_id in the database)
aa.re
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
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
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
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
> instance that is an API analog of ".get(id=self.id)" (although the
> implementat
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
> another library, that library will be pointing at the same
On 12 May 2013, at 00:55, Russell Keith-Magee 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
> another library, that library will be pointing at the same instance. If the
> instance is
On Sat, May 11, 2013 at 4:03 PM, Wim Feijen wrote:
> Hi,
>
> Following up on the discussion on:
>
> https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs
>
> I'd like to start a clear discussion about re-opening ticket 901.
> https://code.djangoproject.com/ticket/901
>
[resend, reference included; sorrt for the noise]
On Saturday 11 May 2013, Anssi Kääriäinen wrote:
>
> - While it might seem trivial to implement reload()/refresh() when
> needed,
Indeed, it might; which is why I would assume many people have already done
it. For these people, a new reload()/
On Saturday 11 May 2013, Anssi Kääriäinen wrote:
>
> - While it might seem trivial to implement reload()/refresh() when
> needed,
Indeed, it might; which is why I would assume many people have already done
it. For these people, a new reload()/refresh() in core may go unnoticed or
redundantly
On 11 touko, 11:03, Wim Feijen wrote:
> Hi,
>
> Following up on the discussion
> on:https://groups.google.com/forum/?fromgroups=#!topic/django-developers...
>
> I'd like to start a clear discussion about re-opening ticket
> 901.https://code.djangoproject.com/ticket/901
>
> Ticket 901 was marked
Hi,
Following up on the discussion on:
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs
I'd like to start a clear discussion about re-opening ticket 901.
https://code.djangoproject.com/ticket/901
Ticket 901 was marked 7 years ago as won't fix and has been subjec
26 matches
Mail list logo
