On Sat, May 11, 2013 at 4:03 PM, Wim Feijen <[email protected]> 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 > > Ticket 901 was marked 7 years ago as won't fix and has been subject of > debate since. > > I must say that I for myself was looking for such a method until I found > that foo = Foo.objects.get(id=foo.id) would work; which did not seem > obvious to me then and now. > The existence of this workaround is probably the single biggest technical reason that this ticket hasn't made any significant progress. > Brandon put forward an argument, which is: > reload() would cover an important use case that did not get a hearing in > the above discussion: that you might already have handed the object off to > some other library, which is keeping a reference from somewhere deep in its > data structures for use when you make a final call to it. If one or more > data structures that are being built already hold the object, then it is > not reasonable to have to track down the object and try to swap in a new > copy everywhere. There should be a simple way to have the existing object's > attributes update in-place. > 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 changed, everywhere holding a handle to that reference will be updated. 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 implementation will need to do a bit more than that). We are *not* talking about ticket #17, object instance caching. Calling refresh() *will not* update *every* instance of a given object. The following would be the effective API: >>> a = MyObj.objects.get(id=42) >>> a.message = 'hello' >>> a.save() >>> b = MyObj.objects.get(id=42) >>> c = MyObj.objects.get(id=42) >>> a.message = 'goodbye' >>> a.save() >>> print b.message 'hello' >>> b.refresh() >>> print b.message 'goodbye' >>> print c.message 'hello' The only place I've had use for this sort of functionality is in test suites, where the test setUp configures some objects, and then a test of a view modifies that object. As a result of calling the view, the database value is changed, but the object held by the test isn't modified in place. In this situation, a call to refresh() would be a nice convenience. However, it's a minor convenience; the "get by pk" trick works fine everywhere I've had this problem. and Anssi thinks it is a good idea to implement this. > > My question is, can we please re-open this ticket and/or discuss here what > are the benefits and drawbacks of having a method reload() ? > > For clarity, this question is in no way meant to be offensive. And if you > want to discuss personal views about this ticket or the behaviour of django > community in general, I politely request you to do so at: > https://groups.google.com/forum/?fromgroups=#!topic/django-developers/DUQtBrM2iTs > Wim - You've done exactly what the core team has asked - you've started a discussion. We're not opposed to discussion, and we're not opposed to saying we're wrong if someone can make a strong case. Nothing you've done or said here is offensive. Yours, Russ Magee %-) -- 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 an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
