Re: dbsettings, and user configurable app settings

[Jared Forsyth]

I think there are some settings which are for the developer, and some which
are appropriate for an admin user, who is not necessarily the developer, to
have access to. In addition, there are some settings which should be
modifiable without necessitating a server restart.
There is value in having configuration options which are available to a user
who doesn't have server write access.

jared

On Wed, Mar 3, 2010 at 8:07 PM, orokusaki  wrote:

> I don't think that settings are for users. They are for the developer.
> The type of settings you are looking for really should be set up as
> part of your application. Users can't choose a DB password or your
> server's time zone, or which apps are installed. If you're creating an
> SAAS you'd be better to have a configuration app that has fields for
> storing account / user specific settings.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: dbsettings, and user configurable app settings

[orokusaki]

I don't think that settings are for users. They are for the developer.
The type of settings you are looking for really should be set up as
part of your application. Users can't choose a DB password or your
server's time zone, or which apps are installed. If you're creating an
SAAS you'd be better to have a configuration app that has fields for
storing account / user specific settings.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Cache, Session and Auth Middleware and Vary: Cookie

[Tamas Szabo]

Hi Tom,


If the view is login required, then you must send 'Vary: cookie',
> there is no option. Consider what would happen if you did not vary on
> the cookie:
>
> Logged in user accesses the page via a caching proxy
> Returned page is cacheable, no Vary header
> Proxy stores page in cache
> Not logged on user requests the page via the proxy
> Proxy retrieves cached, logged on version of the page and delivers it
> to not logged on user
>
> Cheers
>
> Tom
>
>
Yes, you are right, I haven't considered intermediary proxy caches.
I was more concerned about what happens on the browser, as it seems that
Firefox handles the Vary: Cookie as Vary: * (ie. it doesn't use its cache
even if the session cookie is the same).
So, it seems that if Vary: Cookie is set, the only place I can benefit from
caching is on the server-side using Django's cache middleware.
That works fine, but the cache is per-user and t doesn't seem that I can
tell the caching middleware that I don't want that.

It looks like if you have a webapp that requires login for all the pages,
for pages that aren't user specific all you can do currently is to cache
manually in the view.
Is this true?

Ideally, I would like to be able to use the caching middleware in this
scenario by using only configuration + decorators.
Does this makes sense?

Thanks,

Tamas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

[GSOC] Template Compilation

[Alex Gaynor]

Django Template Compilation
===

About Me


I'm a sophomore computer science student at Rensselaer Polytechnic Institute.
I'm a frequent contributor to Django (including last year's successful multiple
database GSoC project) and other related projects; I'm also a commiter on both
`Unladen Swallow `_ and
`PyPy `_.

Background
~~

I've spent quite a bit of time reviewing alternate template implementations,
particularly Spitfire and Jinja, as well as speaking with people like Armin
Ronacher (the author of Jinja). I'm also involved in multiple alternative VMs
for Python, so I'm extremely familiar with the performance characteristics of
various Python operations.

Plan


Compile Django templates into Python functions.

Rationale
~

Currently the Django template language exists at a level above the Python
interpreter, and interprets Django templates. This leads to Django templates
being particularly slow compared to implementations of template languages that
compile templates into Python code.

Method
~~

Templates will be compiled by turning each template into a series of functions,
one per block (note that the base template from which other templates extend is
a single function, not one per block). This is accomplished by taking the tree
of ``Node`` objects which currently exist for a template and translating it
into an alternate representation that more closely mirrors the structure of
Python code, but which still has the semantics of the template language. For
example, the new tree for a loop using the ``{% for %}`` tag would become a for
loop in Python, plus assignments to set up the ``{{ forloop }}`` variable that
the ``{% for %}`` tag provides. The semantics of Python code is that variables
assigned in a for loop exist beyond the loop itself, including the looping
variable. Django templates, however, pop the top layer from the context stack
at the end of a for loop. This intermediate representation uses the scoping of
Django templates.

After an intermediate representation is created a compiler is invoked which
translates the IR into Python code. This handles the details of Django template
scoping, spilling variables in the event of conflicts, and calling template tag
functions.

An important feature of Django templates is that users can write template tags
which have access to the full context, including the ability to modify the
context.  In order to maintain backwards compatibility with existing template
tags, we must create a template context object whenever an uncompilable
template tag is used, and mirror any changes made to the context in the
function's locals.

This presents a complication, as we forfeit the speed benefits of a compiled
template (lookups of a Python local are a single index in a C array) and must
perform a dictionary lookup for every variable. Unfortunately, mirroring a
context dictionary back into local variables requires maintaining a dictionary
of arbitrary names to values, which can't be efficiently implemented with
Python's locals (use of ``exec`` causes locals to degrade to dictionary
lookups).  Furthermore, constructing a dictionary of the full context requires
additional effort.

To provide an optimal solution we must know which variables a given template
tag needs, and which variables it can mutate. This can be accomplished by
attaching a new class attribute to ``Nodes`` and passing only those values to
the class, (instead of the full context dictionary). Subsequently, we would
only need to mirror a few given values into the locals, and since these are
known names, we avoid degrading the local lookups into dictionaries. Old-style
``Nodes`` will continue to work, but in a less efficient manner.

Alternate ideas
---

James Bennett has suggested making template compilation something that is
opt-in by use of a custom template loader. The major advantage of this approach
is that we can require all ``Nodes`` to specify the names they use, and thus
not have to deal with mirroring the locals back and forth, which drastically
reduces the possibility of performance regressions.  I am in favor of going
with this proposal as it gives us a clear transition between the current
implementation and the future (see next section).

Long Term
-

In the short term almost all template tags will be old-style (consider the
number of tags using the "as X" idiom to modify the context). However, a long
term goal should be to move to exclusively compiled template tags.  This has
several benefits:

 * Fewer codepaths to maintain
 * No chance for differing semantics (this follows from the first)
 * More consistant performance.

One of the critical goals of this project will therefore be to develop the API
for template tags in a manner where old-style tags can easily migrate to the
new form.

Examples


The following are some examples 

Re: Abstract models and their managers

[Stephen McDonald]

Hi Russel,

Thanks for your feedback. That's a really interesting position to
learn about with regard to multiple inheritance as I use it all the
time across basic abstract models without any issues.

The approach I was thinking of is very simplistic and possibly naive.
It appears as though I just need to modify
django.db.models.ModelBase.copy_managers to dynamically create the new
managers and assign those to the model class where overlapping
attribute names (eg objects) occur.

If anyone else has any further insight to whether this would work I'd
really appreciate it.

Steve

On Mar 3, 11:52 pm, Russell Keith-Magee 
wrote:
> On Mon, Mar 1, 2010 at 12:40 PM, Stephen McDonald  
> wrote:
> > Hi there,
>
> > I'm just getting an understanding around how managers from abstract
> > models are applied to a subclass model and it appears as though if a
> > model inherits from two abstract models that each define a manager
> > with the same attribute name, eg "objects", then normal mro applies
> > and the derived model picks up the manager from the one abstract model
> > and loses the other one. What are people's thoughts around changing
> > this behaviour so that the derived model's "objects" attribute is
> > actually a newly created type, using each of the abstract models'
> > managers as the bases for the new manager?
>
> > For example the calls at the end of this would work:
>
> > class ManagerA(Manager):
> >    def methodA(self):
> >        pass
>
> > class ModelA(Model):
> >    objects = ManagerA()
> >    class Meta:
> >        abstract = True
>
> > class ManagerB(Manager):
> >    def methodB(self):
> >        pass
>
> > class ModelB(Model):
> >    objects = ManagerB()
> >    class Meta:
> >        abstract = True
>
> > class ModelC(ModelA, ModelB):
> >    pass
>
> > ModelC.objects.methodA()
> > ModelC.objects.methodB()
>
> > It seems to me that this would be desired behaviour especially if the
> > abstract models are parts from separate applications that weren't
> > aware of each other, with each of their managers providing required
> > functionality.
>
> > I've started working on a patch for this and I'm just looking for some
> > feedback before I go any further.
>
> The only feedback I can give is that Django doesn't really support
> multiple inheritance in any capacity at the moment. Most of the
> internals for inheritance assume a single inheritance chain, not an
> inheritance tree. There might be some cases where inheritance it will
> work, but that will be mostly accidental, not intentional, and I
> suspect the model metadata will be a little messed up in those
> situations.
>
> So - you're in pretty much uncharted territory. Any change in this
> area will require some non-trivial plumbing changes. Broadly speaking,
> what you're talking about makes sense (i.e., that the ModelC manager
> should be a composed subclass).
>
> However, be warned - we're unlikely to accept that does the job
> piecemeal. If we're going to pursue multiple inheritance in models,
> we're going to want to ensure that it works across the board, not just
> pick and choose small isolated bugfixes.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 2 small tickets

[Karen Tracey]

On Wed, Mar 3, 2010 at 12:33 PM, Jared Forsyth wrote:

> As a general "best practices" question: When I update a ticket w/ a test
> case and better patch, do I uncheck 'needs better patch' and 'needs
> testcases'? Or do I leave that to the person who originally checked them?
>

If you believe you have addressed whatever made someone set "needs better
patch" you should turn that off.  Similarly if you have added what you
believe are appropriate and sufficient tests, you should turn off "needs
tests".

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: "ImportError: No module named django" with MacPorts

[Karen Tracey]

PLEASE direct questions about using Django to the django-users list. Usage
questions are not on-topic for the django-developers list.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Allowing models to influence QuerySet.update

[Dennis Kaarsemaker]

I know that queryset.update does not call .save() for each instance and
I know why. I even agree with it :)

However, I'd like to have a bit more control over what update() does,
e.g. for auditing purposes. I know that I can simply write a few lines
of code near every update() call to do what I want, but that violates
DRY.

I have created ticket #13021 and uploaded a patch that adds a few new
features:

* pre_update and post_update signals
* a pre_update method for Field that does nothing
* a pre_update method for DateField for auto_now magic
* an update() method for Model that calls pre_update for all fields. 
  This method is a classmethod
* a patched QuerySet.update() that
  - Sends the pre_update and post_update signals
  - Calls the models update method to update the kwargs dict

The patch is untested, but should give a good idea of what I want to
achieve. Is this approach suitable for inclusion in django? If so, I
will complete the patch, add tests and documentation and will submit it
for inclusion at the appropriate time.

Thanks in advance for considering and commenting,
-- 
Dennis K.

The universe tends towards maximum irony. Don't push it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 2 small tickets

[Jared Forsyth]

As a general "best practices" question: When I update a ticket w/ a test
case and better patch, do I uncheck 'needs better patch' and 'needs
testcases'? Or do I leave that to the person who originally checked them?

thanks,
Jared

On Wed, Mar 3, 2010 at 1:08 AM, Russell Keith-Magee
wrote:

> On Wed, Mar 3, 2010 at 3:41 PM, Jared Forsyth 
> wrote:
> > I found some bugs, wrote come patches, submitted some tickets. =) Is that
> > all that's needed?
> > The two patches I wrote are very small, one is only one char diff...
> > I guess I just want to know
> > a) have I done all that's required/suggested, and
>
> As has been noted elsewhere, the big thing missing from both tickets
> is a test case -- or at least a very compelling reason why a test case
> isn't possible.
>
> > b) if so, what's the expected turnaround time for very small bugs w/ a
> patch
> > attached?
>
> "It depends" :-)
>
> Bugs get fixed when they get fixed. The core team are all volunteers,
> so it's impossible for us to make guarantees about when certain bugs
> will be fixed.
>
> Right now, we're trying to push 1.2 out the door, so bugs that are
> critical to that release are taking priority. This means bugs that
> have been introduced in the 1.2 release (regressions, or bugs with new
> features). If this affects your bugs, they should be marked with the
> 1.2 milestone, which improves the chance they will be committed in the
> near future.
>
> If your ticket doesn't meet these criteria, then all I can advise is
> patience.
>
> Yours
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

"ImportError: No module named django" with MacPorts

[Tones]

Hi --

I'm attempting to run Django on OSX 10.6. I've installed Python2.5 and
Py25-Django (Django v1.1) via MacPorts. But I am receiving the famed
"ImportError: No module named django" error.

Django is installed in this directory:
/opt/local/lib/python2.5/site-packages/django/

To check my $PYTHONPATH, I went to the Python shell and tried "print
sys.path". The site-packages path is indeed included in my PYTHONPATH.

However, when I try "print sys.modules" in the same Python shell,
Django is not included.

I can't figure out what's going on. Django's INSTALL.TXT says all
that's needed to install Django is to copy it into the site-packages
directory. But in this case that hasn't worked. Is something else
needed to give Python access to Django?

I suppose I could forget MacPorts and attempt to install from SVN or a
tarball. But I would really prefer to work through the package
manager, especially since it's so unclear what has gone wrong.

Any thoughts appreciated. Thanks!

=Tim=

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: dbsettings, and user configurable app settings

[jedie]

For PyLucid i have made http://code.google.com/p/django-dbpreferences/

"""
A django app defines a form with initial values. The form cleaned data
dict would be stored serialized into the database. The app can easy
get the current preference dict and the user can easy edit the values
in the django admin panel.
"""

Some examples:
http://code.google.com/p/django-dbpreferences/wiki/DBPreferences_example
http://code.google.com/p/django-dbpreferences/wiki/UserSettings_example

Mfg.

Jens

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: No module named project_name.settings

[Karen Tracey]

Please ask questions about using Django on django-users. This list is
for discussion of the development of Django itself.
Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: No module named project_name.settings

[Russell Keith-Magee]

On Wed, Mar 3, 2010 at 5:39 PM, gintare  wrote:
> Hello,
>
> 1) Test.py  complains about missing module
> ImportError: Settings cannot be imported, because environment variable
> DJANGO_SETTINGS_MODULE is undefin
> ed.

Django-developers is for discussing the development of Django itself,
not for answering user questions. Please direct your question to
django-users.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

No module named project_name.settings

[gintare]

Hello,

1) Test.py  complains about missing module
ImportError: Settings cannot be imported, because environment variable
DJANGO_SETTINGS_MODULE is undefin
ed.

I added lines to  python-support.pth file in /usr/lib/python2.5/site-
packages :
/opt/pages/referenc
/opt/pages/referenc/Aref
/opt/pages/referenc/settings.py

sys.path gives output containing:
 '/opt/pages/referenc',  '/opt/pages/referenc/Aref',  '/opt/pages/
referenc/settings.py'

working:/opt/pages/referenc# django-admin runserver --
settings=referenc.settings
Error: Could not import settings 'referenc.settings' (Is it on
sys.path? Does it have syntax errors?): No module named
referenc.settings

### test.py#
#database   /opt/pages/referenc/referenc.db
#table Aref_aref defined in ./referenc/models.py as module
Aref
#table contains many columns, one of which is Rexperimental
#i am inserting empty string "" into column Rexperimental

from models import Aref

if(1==1) :
from django.db import connection, transaction
cursor = connection.cursor()
str1='insert INTO Aref_aref (Rexperimental) values ("");'
a=cursor.execute(str1)
print 'a=', a
###

working:/opt/pages/referenc/Aref# python tests.py
Traceback (most recent call last):
  File "tests.py", line 2, in 
from models import Aref
  File "/opt/pages/referenc/../referenc/Aref/models.py", line 1, in

from django.db import models
  File "/usr/lib/python2.5/site-packages/django/db/__init__.py", line
10, in 
if not settings.DATABASE_ENGINE:
  File "/usr/lib/python2.5/site-packages/django/utils/functional.py",
line 269, in __getattr__
self._setup()
  File "/usr/lib/python2.5/site-packages/django/conf/__init__.py",
line 38, in _setup
raise ImportError("Settings cannot be imported, because
environment variable %s is undefined." %
ENV   IRONMENT_VARIABLE)
ImportError: Settings cannot be imported, because environment variable
DJANGO_SETTINGS_MODULE is undefin
ed.





-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Abstract models and their managers

[Russell Keith-Magee]

On Mon, Mar 1, 2010 at 12:40 PM, Stephen McDonald  wrote:
> Hi there,
>
> I'm just getting an understanding around how managers from abstract
> models are applied to a subclass model and it appears as though if a
> model inherits from two abstract models that each define a manager
> with the same attribute name, eg "objects", then normal mro applies
> and the derived model picks up the manager from the one abstract model
> and loses the other one. What are people's thoughts around changing
> this behaviour so that the derived model's "objects" attribute is
> actually a newly created type, using each of the abstract models'
> managers as the bases for the new manager?
>
> For example the calls at the end of this would work:
>
> class ManagerA(Manager):
>    def methodA(self):
>        pass
>
> class ModelA(Model):
>    objects = ManagerA()
>    class Meta:
>        abstract = True
>
> class ManagerB(Manager):
>    def methodB(self):
>        pass
>
> class ModelB(Model):
>    objects = ManagerB()
>    class Meta:
>        abstract = True
>
> class ModelC(ModelA, ModelB):
>    pass
>
> ModelC.objects.methodA()
> ModelC.objects.methodB()
>
> It seems to me that this would be desired behaviour especially if the
> abstract models are parts from separate applications that weren't
> aware of each other, with each of their managers providing required
> functionality.
>
> I've started working on a patch for this and I'm just looking for some
> feedback before I go any further.

The only feedback I can give is that Django doesn't really support
multiple inheritance in any capacity at the moment. Most of the
internals for inheritance assume a single inheritance chain, not an
inheritance tree. There might be some cases where inheritance it will
work, but that will be mostly accidental, not intentional, and I
suspect the model metadata will be a little messed up in those
situations.

So - you're in pretty much uncharted territory. Any change in this
area will require some non-trivial plumbing changes. Broadly speaking,
what you're talking about makes sense (i.e., that the ModelC manager
should be a composed subclass).

However, be warned - we're unlikely to accept that does the job
piecemeal. If we're going to pursue multiple inheritance in models,
we're going to want to ensure that it works across the board, not just
pick and choose small isolated bugfixes.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Can't search 1.1 documentation on djangoproject.com

[Russell Keith-Magee]

On Wed, Mar 3, 2010 at 5:09 AM, Dougal Matthews  wrote:
> If you head to http://docs.djangoproject.com/en/1.1/ and type in 'settings'
> (for example) into the search on the right you'll notice that all the
> results link to docs.djangoproject.com/en/dev/ rather than /en/1.1/.
> It seems then that 'latest' under the search input is the development
> version and there isn't an option for 1.1? When looking at the results the
> url still contains 1.1 to add to the confusion.
> This could be confusing for people that aren't closely following the new
> features and changes.
> Hopefully I've not missed this somewhere, I searched and couldn't find a
> ticket.

Ticket #10700 is probably the closest match for the problem you
describe. It isn't a perfect match, but any fix for #10700 will
probably encompass a fix for the problem you describe, so there's not
much point opening a new ticket.

I've added a comment to that ticket so that your specific report isn't
forgotten.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Cache, Session and Auth Middleware and Vary: Cookie

[Tom Evans]

On Wed, Mar 3, 2010 at 9:50 AM, Tamas Szabo  wrote:
> Hi,
>
> I've just enabled caching for a Django application and it works great, but
> there is a small problem.
>
> As you know, Session middleware adds a Vary: Cookie header to the response
> and it is smart enough to do that only if the session has been accessed.
>
> This is all good, but the problem is that I have @login_required on the
> majority of my views and although they don't touch the session at all the
> Vary: Cookie header will be added.
> This is because the decorator has to get the user from the session so the
> session middleware sees that the session has been accessed and sets the
> header.
>
> So a simple view like the one below will set the Vary: Cookie header,
> although the result isn't user specific at all and this will prevent
> caching.
>
> @login_required
> def some_view(request)
>     return HttpResponse('Some text')
>
> The ideal solution would probably be to being able to access the session
> without making the session dirty from framework code and then the auth code
> could do just that.
>
> Another possibility is to set the accessed flag back to False from the auth
> code after accessing the user in the session, but I think that needs more
> additional code, because request.user could be accessed from the view and I
> don't think that will set session.accessed = True
>
> Another possibility is to say that this is not a problem / can't be easily
> fixed, but then we probably need a new decorator, so we can mark views as
> @never_varies_on_cookie, because currently I don't think that we can avoid
> having the Cookie added to the Vary header by SessionMiddlewar.
>
> I thought I send an email to django-dev before raising a ticket to get some
> other opinions on the issue.
>
> Thanks,
>
> Tamas

If the view is login required, then you must send 'Vary: cookie',
there is no option. Consider what would happen if you did not vary on
the cookie:

Logged in user accesses the page via a caching proxy
Returned page is cacheable, no Vary header
Proxy stores page in cache
Not logged on user requests the page via the proxy
Proxy retrieves cached, logged on version of the page and delivers it
to not logged on user

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Cache, Session and Auth Middleware and Vary: Cookie

[Tamas Szabo]

Hi,

I've just enabled caching for a Django application and it works great, but
there is a small problem.

As you know, Session middleware adds a Vary: Cookie header to the response
and it is smart enough to do that only if the session has been accessed.

This is all good, but the problem is that I have @login_required on the
majority of my views and although they don't touch the session at all the
Vary: Cookie header will be added.
This is because the decorator has to get the user from the session so the
session middleware sees that the session has been accessed and sets the
header.

So a simple view like the one below will set the Vary: Cookie header,
although the result isn't user specific at all and this will prevent
caching.

@login_required
def some_view(request)
return HttpResponse('Some text')

The ideal solution would probably be to being able to access the session
without making the session dirty from framework code and then the auth code
could do just that.

Another possibility is to set the accessed flag back to False from the auth
code after accessing the user in the session, but I think that needs more
additional code, because request.user could be accessed from the view and I
don't think that will set session.accessed = True

Another possibility is to say that this is not a problem / can't be easily
fixed, but then we probably need a new decorator, so we can mark views as
@never_varies_on_cookie, because currently I don't think that we can avoid
having the Cookie added to the Vary header by SessionMiddlewar.

I thought I send an email to django-dev before raising a ticket to get some
other opinions on the issue.

Thanks,

Tamas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 2 small tickets

[Russell Keith-Magee]

On Wed, Mar 3, 2010 at 3:41 PM, Jared Forsyth  wrote:
> I found some bugs, wrote come patches, submitted some tickets. =) Is that
> all that's needed?
> The two patches I wrote are very small, one is only one char diff...
> I guess I just want to know
> a) have I done all that's required/suggested, and

As has been noted elsewhere, the big thing missing from both tickets
is a test case -- or at least a very compelling reason why a test case
isn't possible.

> b) if so, what's the expected turnaround time for very small bugs w/ a patch
> attached?

"It depends" :-)

Bugs get fixed when they get fixed. The core team are all volunteers,
so it's impossible for us to make guarantees about when certain bugs
will be fixed.

Right now, we're trying to push 1.2 out the door, so bugs that are
critical to that release are taking priority. This means bugs that
have been introduced in the 1.2 release (regressions, or bugs with new
features). If this affects your bugs, they should be marked with the
1.2 milestone, which improves the chance they will be committed in the
near future.

If your ticket doesn't meet these criteria, then all I can advise is patience.

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Eclipse stack trace integration

[Thierry]

Hey Russ

Well it would be a nice addition to the Exception screen.


On 3 mrt, 00:30, Russell Keith-Magee  wrote:
> On Tue, Mar 2, 2010 at 10:00 PM, Thierry  
> wrote:
> > Any idea how to make the file names in the stack trace clickable to
> > open them in eclipse?
>
> > Symfony seems to do it:
> >http://symfony-reloaded.org/tools
>
> > Quote:
> > You can even click on any filename and Symfony will open your favorite
> > IDE at the right line (if you use a supported IDE).
>
> Django-developers is for discussing the development of Django itself.
> Unless you're proposing a specific change to Django to improve IDE
> integration, you should direct your question to Django-users.
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.