Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Django developers
Home
+ new post
About this group
Join this group
Message from discussion 1.0 Feature List Comments
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Philippe Raoult  
View profile  
 More options Mar 21 2008, 6:18 am
From: Philippe Raoult <Philippe.Rao...@gmail.com>
Date: Fri, 21 Mar 2008 03:18:32 -0700 (PDT)
Local: Fri, Mar 21 2008 6:18 am
Subject: Re: 1.0 Feature List Comments
Reply to author | Forward | Print | View thread | Show original | Report this message | Find messages by this author
On Mar 21, 9:10 am, "James Bennett" <ubernost...@gmail.com> wrote:

> And it's irrelevant to a whole lot of use cases, really, because there
> are only two specific situations where it does cause any problems
> you'd be likely to notice:

You should also have a look at #5514. There's a whole class of
situations where you can shoot yourself in the foot because of this.
Having multiple copies of one object in different processes is one
thing (and is expected) but having multiple copies within your own
view is another entirely. And the number of copies you have will
depend on whether you called select_related or not. Having your code
break because you tried to optimize it and added select_related()
isn't nice.

I've been thinking about how to fit #17 in and I think the best use
case is just that: making sure that you have instance uniqueness
*within your view*. Whenever you return from the view everything would
be flushed. Whatever happens in the next view or in another process is
something else entirely and falls into the cache backend scope. This
would solve #5514 -like issues and also provides some performance/
memory gains as an added bonus. It will not break anything that
already works (ie if you had consistency issues between processes
you'll still have to deal with them).

I understand that this is a big change but local instance uniqueness
is really the right thing (tm). If your foreignkeys point to the same
instance in the DB it's reasonable to expect that they do in python
too. Currently #17 only offers a proof of concept but with the
following changes I think it'll be acceptable:
- Make the "cache" flush whenever the view exits (1).
- Provide a simple way to globally enable/disable the cache (we'd
disable it by default).
- Tests! We currently have a few tests in #17 but we need much more.
I'm not really comfortable with the way custom pks are handled, so
this should be tested specifically.

For the record I'm ready to invest some more time into the patch if we
have a consensus that this is a good thing to have.

Philippe

On Mar 21, 9:10 am, "James Bennett" <ubernost...@gmail.com> wrote:

> On Fri, Mar 21, 2008 at 3:03 AM, David Cramer <dcra...@gmail.com> wrote:
> >  It provides uniqueness for all instances of an object throughout
> >  memory. Which, right now, causes major headaches ;)

> For you ;)

> My blog runs on mod_python, with (at peak) maybe a half-dozen
> processes running. Each of those processes might have its own copy or
> even multiple copies of a given Entry object. And I don't care that
> that happens; whether there are a bunch of copies or only one is
> utterly irrelevant to that use case.

> And it's irrelevant to a whole lot of use cases, really, because there
> are only two specific situations where it does cause any problems
> you'd be likely to notice:

> 1. You have staggering numbers of objects in memory, in which case
> multiple copies hurt resource usage (and, to be perfectly honest,
> using a lighter-weight data structure than an instance of Model
> becomes a much better solution for this most of the time).

> 2. Your data fluctuates quickly and often, in which case you want to
> know that the object you're displaying *here* just got changed by the
> form over *there*.

> While these are real use cases, they are not the majority of use
> cases, and so identity mapping in the ORM is not necessarily a
> must-have feature for 1.0. They are important for you, yes, and they
> are important for a number of situations, yes, but we have much bigger
> fish to fry over in the big belly ;)

> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google