Re: Performance Docs

[Russell Keith-Magee]

Hi Alex,

I'll had a look at one of Daniele's initial drafts of this document -- I
don't remember if this point was in the draft I saw, but if it was, I'll
certainly wear some of the blame for this getting committed if it was.

Regardless - having had my attention drawn to it specifically, I'll agree
that it's not exactly well phrased advice.

I completely agree that "Any gains are likely to be small, and
compatibility issues are common." is unsubstantiated FUD.

However, I think there's a good sentiment buried under the actual text --
i.e., make sure you have your house in order, because it's much more likely
the problem lies with bad database queries et al, rather than with Python
itself being slow. The people who are likely to need this document aren't
he seasoned web veterans -- they're the people coming to web programming
(or programming at all) for the first time. Your conversations with people
talking about "IO bound" applications indicates you're already at the
experienced end of the  pool. They're not going to making mistakes that can
be fixed with a select_related() or using memcache, which is the target
audience for this document in my mind.

So - I agree this last section needs work. The focus needs to be on "don't
view PyPy as a silver bullet", not "PyPy is unstable and won't give you a
performance gain".

Yours,
Russ Magee %-)



On Sat, Sep 21, 2013 at 12:04 PM, Alex Gaynor  wrote:

> Hi all,
>
> I didn't follow this PR as it was in progress, but I just sat down and
> read them. I have to say I'm extremely saddened by
> https://docs.djangoproject.com/en/dev/topics/performance/#alternative-software-implementations.
>  This seems like extremely bad advice to me.
>
> In my work I've had the opportunity to do performance work across a huge
> number of applications, and there is an amazing corrolation between people
> who insist their application is strictly IO bound, and applications which I
> find 30% wins in just by switching to PyPy.
>
> PyPy is known to provide substantial performance gains on Django's
> template engine (
> http://speed.pypy.org/comparison/?exe=1%2BL%2Bdefault%2C2%2B472&ben=3&env=1&hor=true&bas=none&chart=normal+bars),
> at the time of writing it's something like 10x.
>
> Further, the claim that "Any gains are likely to be small, and
> compatibility issues are common." is pure FUD, and unsubstantiated.
>
> I'd strongly prefer we remove this from our docs, and if anything we
> should be encouraging the opposite, people with performance issues should
> be encouraged to consider things like PyPy, not hide from them.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

AUTO: Mario Briggs is out of the office -

[Mario Ds Briggs]

I am out of the office until 09/24/2013.

Dad in hospital. Will check email on and off.

contact Varuna Ps Lakshminarayana/India/IBM or Praveen Devarao/India/IBM
for emergencies


Note: This is an automated response to your message  "Abridged summary of
django-developers@googlegroups.com - 41 Messages in 7 Topics" sent on
21/09/2013 9:10:42.

This is the only notification you will receive while this person is away.

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance Docs

[Donald Stufft]

On Sep 21, 2013, at 12:04 AM, Alex Gaynor  wrote:

> Hi all,
> 
> I didn't follow this PR as it was in progress, but I just sat down and read 
> them. I have to say I'm extremely saddened by 
> https://docs.djangoproject.com/en/dev/topics/performance/#alternative-software-implementations
>  . This seems like extremely bad advice to me.
> 
> In my work I've had the opportunity to do performance work across a huge 
> number of applications, and there is an amazing corrolation between people 
> who insist their application is strictly IO bound, and applications which I 
> find 30% wins in just by switching to PyPy.
> 
> PyPy is known to provide substantial performance gains on Django's template 
> engine 
> (http://speed.pypy.org/comparison/?exe=1%2BL%2Bdefault%2C2%2B472&ben=3&env=1&hor=true&bas=none&chart=normal+bars),
>  at the time of writing it's something like 10x.
> 
> Further, the claim that "Any gains are likely to be small, and compatibility 
> issues are common." is pure FUD, and unsubstantiated.
> 
> I'd strongly prefer we remove this from our docs, and if anything we should 
> be encouraging the opposite, people with performance issues should be 
> encouraged to consider things like PyPy, not hide from them.
> 
> Alex
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to 
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> 
> -- 
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.

I agree.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Performance Docs

[Alex Gaynor]

Hi all,

I didn't follow this PR as it was in progress, but I just sat down and read
them. I have to say I'm extremely saddened by
https://docs.djangoproject.com/en/dev/topics/performance/#alternative-software-implementations.
This seems like extremely bad advice to me.

In my work I've had the opportunity to do performance work across a huge
number of applications, and there is an amazing corrolation between people
who insist their application is strictly IO bound, and applications which I
find 30% wins in just by switching to PyPy.

PyPy is known to provide substantial performance gains on Django's template
engine (
http://speed.pypy.org/comparison/?exe=1%2BL%2Bdefault%2C2%2B472&ben=3&env=1&hor=true&bas=none&chart=normal+bars),
at the time of writing it's something like 10x.

Further, the claim that "Any gains are likely to be small, and
compatibility issues are common." is pure FUD, and unsubstantiated.

I'd strongly prefer we remove this from our docs, and if anything we should
be encouraging the opposite, people with performance issues should be
encouraged to consider things like PyPy, not hide from them.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: System check framework

[Russell Keith-Magee]

Hi Chris,

On Sat, Sep 21, 2013 at 4:07 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:

> Hello!
>
> This summer I'm a student of Google Summer of Code. I was working at
> introducing a new system check framework (merging django-secure was a part
> of
> my proposal, but I didn't manage to do it due to my time overestimation).
> The
> project is coming to the end and there is a pull request [1] that is almost
> ready for merging. I would like to present you with the capabilities of the
> framework as well as a high-level overview. I would like to hear your
> opinion
> how the framework can be improved -- this is a last chance for that! This
> thread is a continuation of old "[GSoC] Revamping validation framework and
> merging django-secure once again" thread [2].
>
> [1] https://github.com/django/django/pull/1364
> [2] https://groups.google.com/forum/#!topic/django-developers/fEf21dtpqDE
>
> Here I would like to say thank you to my mentor, Russell Keith-Magee, who
> gave
> me a lot of advices, kept an eye at my project, did reviews and supported
> me.
> Preston Holmes also spent a lot of time reviewing code. Many thanks to
> numerous other contributors!
>

Let me repeat publicly what I said to you on our last call -- Thank *you*
for your efforts over the summer. It was a pleasure to work with you, and
you deserve to be proud of what you've produced.

It's certainly a pity that we didn't get to merging django-secure, but the
codebase you've provided gives us a very strong foundation on which to do
that merge as a post-GSoC activity.

So - now the pressure is on me to do a final review and commit! In the
meantime, I'd encourage anyone with an interest to look over the pull
request and provide feedback.

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[Russell Keith-Magee]

On Sat, Sep 21, 2013 at 3:49 AM, Timothy Anderegg <
timothy.ander...@gmail.com> wrote:

> Hi Luke -
>
> I just wanted to clarify the approach I'm using - The issue of whether or
> not the EmailUser is in contrib.auth or in a new app contrib.auth_email is
> a separate issue from code duplication.
>

This is a key point, and I think the whole conversation warrants a bit of a
reboot.

We have two key questions here:

 1) Where does the new model live? Is it going to live in contrib.auth, or
in a new contrib.email_auth package?

 2) Exactly what does the new class hierarchy look like? Are we going to do
any refactoring of AbstractUser? How many composable bits are we going to
end up with?

We've had a lot of discussion on question 1, which is risking becoming a
bit of a bikeshed on the interpretation of `swappable`.

What I haven't seen is a whole lot of clear discussion on point 2. Most of
the discussion seems to stop at "use package/patch X", rather than a
providing a good  summary of the consequences.

Correct me anyone disagrees, but my impression is that the endpoint isn't
under dispute -- we're aiming at adding a new User model that is an exact
analog of the existing User model, but with email as the USERNAME_FIELD.
However, there are a couple of ways we can make this happen (ranging from
simple copy/paste to a complex mixin/inheritance hierarchy). Speaking as
the person from core who wants/needs to commit this, I need to see options
for *this* part of the discussion.

I've just put a summary of these two points on the wiki; I'd invite anyone
with an opinion to weigh in. As always, try to remain impersonal and
objective. I'd also appreciate people who have contributed to the
'Implementation' section to tie back to the new design section -- if you've
proposed a codebase, describe which design decisions you've made.

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[Russell Keith-Magee]

On Sat, Sep 21, 2013 at 2:43 AM, Luke Sneeringer wrote:

>
> P. S. I'm not the sharpest knife in the drawer when it comes to social
> things, so I want to state explicitly: I am continuing to debate the
> question because I perceive the debate to be moving in a useful way. If
> I'm, in fact, simply being confrontational, then tell me to shut up and
> I'll just work on doing it your way / commenting on tanderegg's start. At
> the end of the day, I recognize that it is your decision to make, and at
> the end of the day, if I can't convince you, I'll accept it with a smile
> and get the work done! I definitely want to be offering a positive
> contribution.


Understood -- and FTR, I wasn't getting a confrontational vibe; the fact
that you're aware that this concern even exists means you're almost
certainly not over the line :-)

And, flipping it around -- I'm not trying to be confrontational either -
also just looking out for the best interests of Django (as I see them).

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[Russell Keith-Magee]

Hi Gavin,

On Sat, Sep 21, 2013 at 12:58 AM,  wrote:

> > The intention was to mark a particular model as a something that can be
> replaced.
>
> It's hard to find the original rationale behind swappable, but my mental
> model was always:
>
>   A model with `swappable = 'x'` means that the model should only be
> loading if settings.x is set to that same model
>

Well, it's hard to find the rationale because it's an internal API that
(like the rest of Meta) isn't documented. However, I can speak with
authority on the original rationale, because I was the person who wrote the
code, and I had a specific intention in mind :-)

> it's still not desirable.
>
> Why not? Swappable seems like exactly what we need here.
>
> > No other User model needs to [set swappable]
>
> This would still be the case. Only models that want to conditionally load
> themselves would set swappable. User models in application code probably
> wouldn't set it, because the project will always use that one user model.
>
> > ... made a special case of "Swappable models in the same app".
>
> I'm not sure where there's a special case. Swappable works for this
> without any modifications, see authtools.
>

This all hinges on the interpretation. My intention was *not* that
swappable meant "This model might not be loaded". My intention *was* that
swappable meant "This particular model is an extension point that might be
replaced by a third party."

As I've indicated elsewhere, the fact that the implementation happens to
support the first interpretation is accident, not intention.


> > *Any* model can be swapped in as a substitute user.
>
> Yep. Nothing needs to change to keep this possible.
>
> > If we were to go down this path, the logical extension (to my mind)
> would be to validate that you're not swapping in a model that hasn't
> declared itself as swappable
>
> Why would you want to validate this? Swappable only controls loading of
> the model its set on, there is no action-at-a-distance on other models.
>
> > Secondly, marking a model as swappable doesn't make it zero cost.
>
> That's fair. I'll add it to the wiki as a disadvantage.
>

And this remains my biggest reason why the first interpretation isn't the
right interpretation. We shouldn't be encouraging people to build
monolithic apps containing dozens of "swappable" models. We should be
encouraging people to write small, tight apps that fill a single purpose.


> > So far, the only convincing argument I've heard for putting the
> EmailUser in contrib.auth is that it avoids having to add a value to
> INSTALLED_APPS.
>
> I don't think we should focus so much on the optional part of the
> proposal. The really important part is to refactor the existing code to
> work better with custom users. Once this happens, projects like authtools
> can trivially add an EmailUser in a few lines of code, so it's not so
> important that there's one in core.
>

I'm not sure exactly what you mean by the "optional" part of the proposal.
Where the code will sit seems like a pretty important question to me. There
are other questions to be resolved as well, but it seems to me that those
discussions are currently being swamped. I may need to a reboot of this
conversation.

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Curtis Maloney]

OK.  So the goals of this effort are:

1) to avoid resource over commitment [e.g. too many connections]
2) to help relieve the burden of concurrency from the cache backends.

Issues to avoid are:
a) TLS is "slow" (citation, please?)
b) New API better damn well be worth it!

Is there anything else?

--
Curtis


On 21 September 2013 01:29, Tom Evans  wrote:

> On Fri, Sep 20, 2013 at 4:13 PM, Florian Apolloner
>  wrote:
> >> It seems more sensible to hook something that has the lifetime of the
> >> request to the request, rather than stick it in TLS, keyed to the
> >> thread serving the request.
> >
> >
> > Jupp, sadly I don't see a sensible way around thread local storage here
> :(
> >
>
> All good points, I just have this mental "HMM" when I see TLS as the
> solution for anything. TLS is already used for things like the
> language code of the current request, which avoids you having to pass
> around a state object or passing down lang_code all down the stack,
> but means that things like URL reversing and resolving benchmarks are
> slow (O(n²)) with USE_I18N on.
>
> The problem with tying everything to the request is that you end up
> with code that only works with requests or request-like-objects. The
> problem with not tying everything to the request is that things get
> slower. :(
>
> Cheers
>
> Tom
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

In order to get more attention, I've created a new thread [1].

[1] https://groups.google.com/forum/#!topic/django-developers/_sde4eoNRyQ

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

System check framework

[Christopher Medrela]

Hello!

This summer I'm a student of Google Summer of Code. I was working at
introducing a new system check framework (merging django-secure was a part 
of
my proposal, but I didn't manage to do it due to my time overestimation). 
The
project is coming to the end and there is a pull request [1] that is almost
ready for merging. I would like to present you with the capabilities of the
framework as well as a high-level overview. I would like to hear your 
opinion
how the framework can be improved -- this is a last chance for that! This
thread is a continuation of old "[GSoC] Revamping validation framework and
merging django-secure once again" thread [2].

[1] https://github.com/django/django/pull/1364
[2] https://groups.google.com/forum/#!topic/django-developers/fEf21dtpqDE

Here I would like to say thank you to my mentor, Russell Keith-Magee, who 
gave
me a lot of advices, kept an eye at my project, did reviews and supported 
me.
Preston Holmes also spent a lot of time reviewing code. Many thanks to
numerous other contributors!

Now let me introduce you the framework.

*Overview*

I've introduced a new system check framework that replaces the old 
validation
framework performing mainly model validation. The new framework is 
responsible
for model validation, app-specific checks like ModelAdmin validation as well
as compatibility checks. It introduces concept of warnings. Warnings as well
as errors can be silenced. The framework is open-ended which means that you
can register your own check stuff.

*Messages*

The framework uses a concept of messages similar to messages from message
framework or logging framework. A message can be a light message like a
warning, info or debug; or a serious message, e.g. an error or critical
(error). Every message consists of four attributes:

   - required error message (`msg`);
   - optional `hint`; in order to force developers to think carefully if 
   they
   cannot provide any useful hint, they need to explicitly pass hint=None in
   that case;
   - optional invalid object (`obj`);
   - optional unique message identifier (`id`) used to refer to messages, 
   i.e.
   "E001" (a core error) or "admin.W001" (a warning issued by admin app).

*Performing checks*

In order to perform all kinds of checks, type:

python manage.py check

This command does the same stuff as the old `validate` and `check` commands.
`validate` is now deprecated and delegates to `check` command.

You can still validate some specific apps:

python manage.py check admin auth

Or you can run a subset of checks labeled with a given tag:

python manage.py -t compatibility  # alternative: --tag compatibility

*Silencing errors/warnings*

A new setting called SILENCED_SYSTEM_CHECKS was introduced. It's a list of
message identifiers. If you put on the list a light message like a warning, 
it
won't be printed anymore. Putting on the list a serious message like an 
error
won't hide the message, but will allow you to i.e. run server.

*Registering your own stuff*

If you want to add a new check, you need to write a function that accepts
`apps` and `**kwargs` arguments where `apps` is a list of applications that
should be validated (or None if all apps should be validated). The function
should return a list of messages, even if it's an empty list. Finally, you
need to register this entry point. Let's look at this snippet implementing
some security checks:

from django.conf import settings
from django.core import checks

# Label this entry point with 'security' tag. This tag can be used while
# invoking check command, e.g. you can write `./manage.py -t security`.
@checks.register('security')
def my_security_check(apps, **kwargs):
# This check does not perform any app-specific checks, so if we are
# asked to validate some specific apps, we can skip checks.
if apps is not None:
return []

if len(settings.SECRET_KEY) < 64:
return [
checks.Warning(
'Your SECRET_KEY is too short.',
hint=None,  # need to explicitly pass hint even if you 
cannot provide any hint
obj='settings.SECRET_KEY',
id='security.W001',
)
]
else:
return []

*Field/model/manager checks*

You don't have to register your check stuff if it's called from another 
piece
of code that is registered (directly or indirectly). This is true especially
in the case of fields, models and managers. Each of these object have 
`check`
method (or classmethod in the case of models) that can be overriden in order
to add some validation stuff. Consider that you implemented a field that
accepts only values from [min, max] range and you want to check if min < 
max.
Here is a snippet of code:

from django.core import checks
from django.db import models

class RangedIntegerField(models.IntegerField):
def __init__(self, min=

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

[Aymeric Augustin]

On 20 sept. 2013, at 10:32, Richard Ward  wrote:

> I'll open a ticket about the docs later today.

I just took a few minutes to write a patch:
https://github.com/django/django/commit/4db2752e28668ed8826b770ef2ed26e8c1562db6

Let me know if you think it can be improved.

-- 
Aymeric.




-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: System check framework

[Carl Meyer]

Hi Christopher,

On 09/20/2013 02:07 PM, Christopher Medrela wrote:
> This summer I'm a student of Google Summer of Code. I was working at
> introducing a new system check framework (merging django-secure was a
> part of
> my proposal, but I didn't manage to do it due to my time
> overestimation). The
> project is coming to the end and there is a pull request [1] that is almost
> ready for merging. I would like to present you with the capabilities of the
> framework as well as a high-level overview. I would like to hear your
> opinion
> how the framework can be improved -- this is a last chance for that! This
> thread is a continuation of old "[GSoC] Revamping validation framework and
> merging django-secure once again" thread [2].
> 
> [1] https://github.com/django/django/pull/1364
> [2] https://groups.google.com/forum/#!topic/django-developers/fEf21dtpqDE
> 
> Here I would like to say thank you to my mentor, Russell Keith-Magee,
> who gave
> me a lot of advices, kept an eye at my project, did reviews and
> supported me.
> Preston Holmes also spent a lot of time reviewing code. Many thanks to
> numerous other contributors!
> 
> Now let me introduce you the framework.

I haven't had the time this summer to keep up with your progress, but
based on your summary here, this looks really excellent! Thanks for your
work.

Carl

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[Timothy Anderegg]

Hi Luke -

I just wanted to clarify the approach I'm using - The issue of whether or
not the EmailUser is in contrib.auth or in a new app contrib.auth_email is
a separate issue from code duplication.  Either way, you'd have to create
new versions of UserCreationForm, UserChangeForm, UserAdmin, and
UserManager, because each of those classes will only work with the default
auth.User model (as currently written).

So there's really two independent questions at play here:

1) Should a new EmailUser model be in contrib.auth or contrib.auth_email?

Based on the current recommended way to use swappable, EmailUser should be
in its own app contrib.auth_email.  This could be changed by "blessing" the
usage of swappable that Aaron was talking about (which does seem to work),
in which case EmailUser could be in the contrib.auth app without conflicts.
 Testing would have to be done to make sure this works in all cases.

2) Should contrib.auth undergo refactoring to reduce the amount of code
duplication required to create a custom user model?

This would require modifying the two forms, admin class, and user manager
to support custom models without further subclassing (except to add new
functionality) or replacement.  I did this for UserManager in my
alternative patch (
https://github.com/tanderegg/django/compare/ticket_20824_refactor_master),
which was fairly straightforward although a little awkard since the current
public api requires a separate parameter passed to create_user for email,
even if 'email' is also being used as the username.

The forms and admin class would be a bit harder, it could be done but the
result would probably be a bit convoluted, and they still would not cover
all use cases of course.  Better would be to create abstract base classes
for those forms and UserAdmin that cover essential functionality, and then
allow custom models to inhereit from those, which would reduce code
duplication fairly substantially.  If we used abstract base classes though,
the custom user model would still require defining custom forms and admin
classes as well, they would just be much simpler.

-Tim


On Fri, Sep 20, 2013 at 2:47 PM, Luke Sneeringer wrote:

>
> On Sep 20, 2013, at 10:58 AM, gavinw...@gmail.com wrote:
>
> > > No other User model needs to [set swappable]
> >
> > This would still be the case. Only models that want to conditionally
> load themselves would set swappable. User models in application code
> probably wouldn't set it, because the project will always use that one user
> model.
>
> This is my understanding too. If you set a user model in individual
> project code, there's no point in defining it as swappable, as that project
> is always going to want to use it.
>
> If you're writing the authtools app, you probably do want to define the
> user model or models you offer as swappable, but that seems like it's still
> true now.
>
> > > ... made a special case of "Swappable models in the same app".
> >
> > I'm not sure where there's a special case. Swappable works for this
> without any modifications, see authtools.
> >
> > > *Any* model can be swapped in as a substitute user.
> >
> > Yep. Nothing needs to change to keep this possible.
> >
> > > If we were to go down this path, the logical extension (to my mind)
> would be to validate that you're not swapping in a model that hasn't
> declared itself as swappable
> >
> > Why would you want to validate this? Swappable only controls loading of
> the model its set on, there is no action-at-a-distance on other models.
>
> I, too, don't really understand this assumption. The status quo works just
> fine, and makes complete sense to me.
>
> > I don't think we should focus so much on the optional part of the
> proposal. The really important part is to refactor the existing code to
> work better with custom users. Once this happens, projects like authtools
> can trivially add an EmailUser in a few lines of code, so it's not so
> important that there's one in core.
>
> Eh, I pretty passionately believe that this particular use case needs to
> be in core. It's **really** common. But, the point that you make is why I
> am passionate about not just making an auth_email app, because I see the
> other approach as *also* having more value in simplifying some other
> more-simple user substitutes.
>
> L
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/rb7v9kVAK3I/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django develop

Re: AbstractUser to get more abstract

[Luke Sneeringer]

On Sep 20, 2013, at 10:58 AM, gavinw...@gmail.com wrote:

> > No other User model needs to [set swappable]
> 
> This would still be the case. Only models that want to conditionally load 
> themselves would set swappable. User models in application code probably 
> wouldn't set it, because the project will always use that one user model.

This is my understanding too. If you set a user model in individual project 
code, there's no point in defining it as swappable, as that project is always 
going to want to use it.

If you're writing the authtools app, you probably do want to define the user 
model or models you offer as swappable, but that seems like it's still true now.

> > ... made a special case of "Swappable models in the same app".
> 
> I'm not sure where there's a special case. Swappable works for this without 
> any modifications, see authtools.
> 
> > *Any* model can be swapped in as a substitute user. 
> 
> Yep. Nothing needs to change to keep this possible.
> 
> > If we were to go down this path, the logical extension (to my mind) would 
> > be to validate that you're not swapping in a model that hasn't declared 
> > itself as swappable
> 
> Why would you want to validate this? Swappable only controls loading of the 
> model its set on, there is no action-at-a-distance on other models.

I, too, don't really understand this assumption. The status quo works just 
fine, and makes complete sense to me.

> I don't think we should focus so much on the optional part of the proposal. 
> The really important part is to refactor the existing code to work better 
> with custom users. Once this happens, projects like authtools can trivially 
> add an EmailUser in a few lines of code, so it's not so important that 
> there's one in core.

Eh, I pretty passionately believe that this particular use case needs to be in 
core. It's **really** common. But, the point that you make is why I am 
passionate about not just making an auth_email app, because I see the other 
approach as *also* having more value in simplifying some other more-simple user 
substitutes.

L

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[Luke Sneeringer]

On Sep 19, 2013, at 11:15 PM, Russell Keith-Magee  
wrote:

> Firstly, it leads to inconsistent usage of API. Under the current scheme, the 
> default User model defines swappable. No other User model needs to. In your 
> proposed usage, you've just made a special case of "Swappable models in the 
> same app". Now, granted - this discrepancy isn't something that needs to be 
> documented (because swappable isn't documented), but if someone goes looking, 
> or if we ever want to formalise swappable (which is certainly my long term 
> hope), we need to explain why some models need swappable defined and others 
> don't.

If we went with this method, the explanation would be that a model must define 
itself as swappable if the intent is for it to be able to be overridden.

So, the idea would be that any user model that we chose to ship in Django 
should be marked swappable, but the User model that someone wrote for their own 
app would not be.

Even if we decide to go with an auth_email app, we should almost certainly 
still mark that User model as swappable. (What if someone wanted the forms and 
not the model?)

> Alternatively, if we change the game to say that swappable *is* required on 
> all models, then we have a backwards compatibility problem (because no 
> existing custom user model needs swappable to be defined). *Any* model can be 
> swapped in as a substitute user. 

I completely agree. Any setup that requires swappable on all models does not 
make sense. But simply marking swappable on models that *we* ship that are 
intended to be able to be subbed out does make sense, and doesn't cause 
back-compat issues.

Right now Django ships one model: User, marked swappable. By declaring your own 
model and setting it as AUTH_USER_MODEL, the swappable setting makes it so that 
ours is not used.

I am proposing that Django would ship two models: User and EmailUser, both 
marked swappable. If you declare your own, neither of ours are used. If you use 
one of ours, the other is not used. If you go the declare your own route, there 
is no need to mark your model as swappable. It is, as you state, a regular 
model.

> If we were to go down this path, the logical extension (to my mind) would be 
> to validate that you're not swapping in a model that hasn't declared itself 
> as swappable (otherwise, why would you go to the trouble of predeclaring?). 
> This *isn't* currently being done, and I'm not convinced it has value. This 
> is an instance where duck typing works really well. There's also the example 
> I raised about comments on User - you aren't necessarily in control of the 
> model that you want to use as a swappable alternative.

I agree here too. I don't think this idea has value. However, I don't think 
it's a necessary condition, either.

> Lastly, we have consistency with external usage, and the benefits of 
> documentation by example. Current usage says that use a custom User model, 
> you add the app the INSTALLED_APPS and set AUTH_USER_MODEL. By shipping 
> email_auth as a separate app, we'd be continuing the same advice, and the app 
> would serve as a helpful example for how to do it. We'd be eating our own dog 
> food/leading by example.
> 
> So far, the only convincing argument I've heard for putting the EmailUser in 
> contrib.auth is that it avoids having to add a value to INSTALLED_APPS. And 
> I'm afraid that, by itself, just doesn't convince me. Everything I see 
> suggests that a standalone app is cleaner and more explicit, and serves as a 
> better example to the wider community. I just don't consider an extra entry 
> in INSTALLED_APPS -- explicitly saying "I want to have access to this extra 
> model", the same way you do for *every* other Django app -- is onerous.

I have two reasons for wanting this method: one is the public API, but the 
other (maybe bigger) is code duplication. Django is about DRY, after all. If we 
do an auth_email model, we have to largely duplicate the model, and the form, 
and any relevant views.

If we ship an email user model, what seems the path of least resistance to me 
would be to have the existing User subclass EmailUser, add the username field 
and redefine USERNAME_FIELD and REQUIRED_FIELDS. Things like (for example) 
UserCreationForm would be defined to have the two password fields and then have 
the username field derived from the field that is declared as USERNAME_FIELD. 
This has the expedient side effect of making it useful for more substitution 
models in the wild, although obviously not all of them. You've been referring 
to a reference implementation as a valuable aspect of the separate-app route, 
but one of the virtues of my proposal is that it increases the number of cases 
where much less has to be implemented at all.

tanderegg's implementation really hits this home for me: he has models, forms, 
etc. that all look almost-but-not-quite-exactly like the ones already being 
shipped. That also means double maintenance -- if we want to ma

Re: Default session data serializer doesn't support extended data types

[Florian Apolloner]

On Friday, September 20, 2013 4:40:39 PM UTC+2, Curtis Maloney wrote:
>
> And the answer is: there's no way for a matching Decoder to know when to 
> decode any of these types, since there's no schema available.
>

Good point, it would be doable by serializing into something like '{_type: 
datetime, value: 2012…}' but I doubt that's really sensible. 

>
> The only "simple" alternative that comes to mind is something like 
> MsgPack, with a bunch of pre-defined Extension types.
>
> As far as the security benefits, I think Donald has nailed it -- no part 
> of the system should base its security around relying on the integrity of 
> any other part.
>
> --
> Curtis
>
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[gavinwahl]

> The intention was to mark a particular model as a something that can be 
replaced.

It's hard to find the original rationale behind swappable, but my mental 
model was always:
  
  A model with `swappable = 'x'` means that the model should only be 
loading if settings.x is set to that same model

> it's still not desirable.

Why not? Swappable seems like exactly what we need here.

> No other User model needs to [set swappable]

This would still be the case. Only models that want to conditionally load 
themselves would set swappable. User models in application code probably 
wouldn't set it, because the project will always use that one user model.

> ... made a special case of "Swappable models in the same app".

I'm not sure where there's a special case. Swappable works for this without 
any modifications, see authtools.

> *Any* model can be swapped in as a substitute user. 

Yep. Nothing needs to change to keep this possible.

> If we were to go down this path, the logical extension (to my mind) would 
be to validate that you're not swapping in a model that hasn't declared 
itself as swappable

Why would you want to validate this? Swappable only controls loading of the 
model its set on, there is no action-at-a-distance on other models.

> Secondly, marking a model as swappable doesn't make it zero cost. 

That's fair. I'll add it to the wiki as a disadvantage.

> So far, the only convincing argument I've heard for putting the EmailUser 
in contrib.auth is that it avoids having to add a value to INSTALLED_APPS.

I don't think we should focus so much on the optional part of the proposal. 
The really important part is to refactor the existing code to work better 
with custom users. Once this happens, projects like authtools can trivially 
add an EmailUser in a few lines of code, so it's not so important that 
there's one in core.

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: AbstractUser to get more abstract

[tanderegg]

Hi Luke - 

I just wanted to let you know that I've already started a patch on this, 
you can see it here: 
https://github.com/tanderegg/django/compare/ticket_20824_master  If you 
want to reduce duplicated effort, please take a look at what I have so far 
and let me know what you think!

Russ, Aaron -

I tend to agree with Russ here that it makes sense to keep auth_email as a 
separate app, especially if swappable is not meant to be used on any model 
other than auth.User.  If EmailUser was also put into auth, not only would 
it create an unesseccary set of tables, it also would cause m2m accessor 
clashes with groups and permissions.  Additionally, it provides a 
"template" of sorts for others to refer to if they want to roll their own 
user models.

That said, even if we use a separate app, we might benefit from refactoring 
AbstractUser a bit.  I could see the following chain:

AbstractBaseUser -> 
AbstractPermissionsUser (ass ins Permissions Mixin) -> 
AbstractEmailUser (just adds email field and email_user method) -> 
AbstractNamedUser (adds first_name and last_name) -> 
AbstractUser (retains same API as before)

The advantage of doing this would be to remove some code duplication from 
auth_email.EmailUser, and to create a few more inheritance opportunities 
for scenarios where someone wants a user with no name fields, or if they 
want to implement their own naming conventions, or if they want permissions 
but no email and name.

Here's an example of what that might look like: 
https://github.com/tanderegg/django/compare/ticket_20824_refactor_master  I 
also modified the UserManager class to support any of these abstract models.

The main issue with doing this is that email would now be required for all 
users (which could be avoided by removing AbstractEmailUser from the 
inheritance chain and adding an email field to AbstractUser), and to 
maintain backwards compatibility, UserManager.create_user would require 
passing the email twice, once as username and once as email, for any model 
that uses email as the username (which could be avoided by overriding in a 
sub class when using email as username).

Not sure if this refactoring would help all that much in the grand scheme 
of things though.

-Tim

On Thursday, September 12, 2013 4:44:53 PM UTC-4, Abdulaziz Alfoudari wrote:
>
> This is a continuation of my post on 
> stackoverflow
> .
>
> With the introduction of Django 1.5, it was possible to create a custom 
> User model which is flexible enough to have any user profile the developer 
> wants created. However, looking at a very common problem which is using the 
> email as the primary user identifier instead of username, the solution 
> requires copying most of Django's internal definition of AbstractUser and 
> that is only to remove the username field.
>
> A better solution in my opinion is make AbstractUser even more abstract by 
> removing username field, and allowing the developer to explicitly specify 
> the field to be used as the user identifier. This will require a tiny extra 
> work for those that use the current default behavior, but it will also 
> greatly reduce the work needed for the very common problem of using email 
> as the user identifier.
>
> Please share your thoughts and opinions on this.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

Hi Tom,

On Friday, September 20, 2013 5:04:41 PM UTC+2, Tom Evans wrote:
>
> On the other hand each call to get_cache('foo') now requires access to 
> TLS. TLS is slw. Going through something slow to get to something 
> that is supposed to be a speed up... 
>

You are making a good point, even though I do think that TLS is still way 
faster than anything waiting for IO (python has a python implementation of 
threading.local and a c implementation).

Would it be better to leave the API and semantics of get_cache alone 
> and provide a new way of accessing caches through the request object, 
> leaving them cached on the request object for the duration of the 
> request, and thus avoiding the need of TLS. 
>

I would prefer to have one API, but I think it would be okay for cache 
backends them self to specify that the shouldn't be put into a thread local 
storage (probably via a simple attribute). Does that sound like a solution 
to you? LocMemCache seems to be a candidate for that. 
  

> Requests aren't shared between threads, and so a 
> per request cache would be inherently thread safe. 
>

The same argument holds true for let's say django db connections; but I 
doubt it's gonna fly; eg passing request into get_cache as storage object 
seems somewhat nasty (at least as long as we name it request ;))
 

> It seems more sensible to hook something that has the lifetime of the 
> request to the request, rather than stick it in TLS, keyed to the 
> thread serving the request.
>

Jupp, sadly I don't see a sensible way around thread local storage here :(

Cheers,
Florian 

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Tom Evans]

On Fri, Sep 20, 2013 at 4:13 PM, Florian Apolloner
 wrote:
>> It seems more sensible to hook something that has the lifetime of the
>> request to the request, rather than stick it in TLS, keyed to the
>> thread serving the request.
>
>
> Jupp, sadly I don't see a sensible way around thread local storage here :(
>

All good points, I just have this mental "HMM" when I see TLS as the
solution for anything. TLS is already used for things like the
language code of the current request, which avoids you having to pass
around a state object or passing down lang_code all down the stack,
but means that things like URL reversing and resolving benchmarks are
slow (O(n²)) with USE_I18N on.

The problem with tying everything to the request is that you end up
with code that only works with requests or request-like-objects. The
problem with not tying everything to the request is that things get
slower. :(

Cheers

Tom

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Tom Evans]

On Fri, Sep 20, 2013 at 3:10 PM, Florian Apolloner
 wrote:
> The main issue here isn't recreating the objects on demand, but the impact
> they have, eg a new memcached connection. Now imagine a complex system where
> each part issues get_cache('something') to get the cache

On the other hand each call to get_cache('foo') now requires access to
TLS. TLS is slw. Going through something slow to get to something
that is supposed to be a speed up...

> and you'll end up
> with a few connections per request instead of one.

Would it be better to leave the API and semantics of get_cache alone
and provide a new way of accessing caches through the request object,
leaving them cached on the request object for the duration of the
request, and thus avoiding the need of TLS.

The reason to use TLS is because requests are commonly served from
threaded servers, and cache clients may not be thread safe, so a
desire to stop different requests from simultaneously accessing the
same cache client. Requests aren't shared between threads, and so a
per request cache would be inherently thread safe.

It seems more sensible to hook something that has the lifetime of the
request to the request, rather than stick it in TLS, keyed to the
thread serving the request.

Cheers

Tom

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Florian Apolloner]

On Friday, September 20, 2013 3:52:30 PM UTC+2, Davide Rizzo wrote:
>
> On Friday, September 20, 2013 2:55:33 PM UTC+2, Florian Apolloner wrote:
>>
>> Btw could it be that you are mixing out Encoder and Serializer?
>>
>
> No, I say Serializer when I mean... well, a serializer, as specified by 
> SESSION_SERIALIZER. I say Encoder when I mean the Encoder class used by 
> JSONSerializer. It could be the one built into the json module, or it could 
> be a derived one, such as DjangoJSONEncoder here 
> https://github.com/django/django/blob/1.6b4/django/core/serializers/json.py#L79
>

Ok, I though as much, but wanted to be sure. 

It's either to change the default to PickleSerializer
>

Most likely not gonna happen since we choose secure by default.

or to mitigate the JSONSerializer issue supporting these data types:
>
>- datetime, timedelta objects (supported by DjangoJSONEncoder)
>- decimal objects (supported by DjangoJSONEncoder)
>- arbitrary binary strings (b'\xe8')
>- Geometry objects
>
> I could live with using DjangoJSONEncoder, but support for arbitrary 
binary strings and geometry objects would have to come via that instead of 
beeing specialized for sessions. That said, it's quite late for 1.6, so the 
patch would have to be rocksolid and would require agreement of the rest of 
the core devs.
 

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Curtis Maloney]

I talked with the OP [or someone who talks a _lot_ like the OP:)] on IRC
about this issue before recommending they open a ticket... and aside from
anything else discussed, since someone already saw fit to include an
extended JSONEncoder class in core/serializers, why doesn't the session
machinery re-use it?

All it does is add support for date, time, datetime and Decimal.

And the answer is: there's no way for a matching Decoder to know when to
decode any of these types, since there's no schema available.

The only "simple" alternative that comes to mind is something like MsgPack,
with a bunch of pre-defined Extension types.

As far as the security benefits, I think Donald has nailed it -- no part of
the system should base its security around relying on the integrity of any
other part.

--
Curtis

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

Hi Tom,

On Friday, September 20, 2013 3:29:03 PM UTC+2, Tom Evans wrote:
>
> Before you 
> go too far down the thread local route, could you verify that 
> retrieving cache objects from a thread local cache is in any way 
> faster than simply recreating them as demanded. 
>

The main issue here isn't recreating the objects on demand, but the impact 
they have, eg a new memcached connection. Now imagine a complex system 
where each part issues get_cache('something') to get the cache and you'll 
end up with a few connections per request instead of one.

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Donald Stufft]

On Sep 20, 2013, at 9:52 AM, Davide Rizzo  wrote:

> The examples you mentioned (forms, admin) were significant improvements 
> themselves, with big benefits to Django users. Switching the default session 
> serializer to JSONSerializer is providing no benefit to any user. It's 
> addressing a security problem (which is already documented) that only a few 
> users have (can you provide a big^H^H^H list of users who use signed cookies 
> but can't add a SESSION_SERIALIZER setting next to their 
> SESSION_COOKIE_HTTPONLY and SESSION_COOKIE_SECURE settings?).

This isn't exactly true. While it *is* true that the biggest risk to using 
pickle as the session serialization is if you're using the cookie storage 
engine, it is *not* true that it is the only place that it can be attacked. 
Particularly it can be used to daisy chain from a compromised database, 
memcache, redis, etc host (wherever you're storing your sessions) to exploiting 
the app server.

A basic tenant in securing systems is that you make each piece of the system 
responsible for it's own security and you don't have it depend on the security 
of another system. Moving away from pickle as the default serialization engine 
ensures this property for the storage of session data.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Default session data serializer doesn't support extended data types

[Davide Rizzo]

On Friday, September 20, 2013 2:55:33 PM UTC+2, Florian Apolloner wrote:
>
>
> Btw could it be that you are mixing out Encoder and Serializer?
>

No, I say Serializer when I mean... well, a serializer, as specified by 
SESSION_SERIALIZER. I say Encoder when I mean the Encoder class used by 
JSONSerializer. It could be the one built into the json module, or it could 
be a derived one, such as DjangoJSONEncoder here 
https://github.com/django/django/blob/1.6b4/django/core/serializers/json.py#L79

Personally I don't see any improvement in using an extended encoder -- in 
> the end it's just more work for us and people complaining why we don't 
> support their $magical class. In most if not all cases storing full objects 
> in the session is wrong; what we could have supported would be timestamps, 
> but those are storable as utc seconds easily enough… Why would the current 
> status be discouraging anyone?
>

Easily enough is still more complicated than current solution storing 
datetime objects, possibly with tzinfo. It's discouraging to the users 
because, after you find out what the problem is, it's easier to revert to 
PickleSerializer (with no security compromise, if you don't use 
SignedCookies) than to circumvent the extra difficulties of adapting one's 
local status data to JSON. And third party apps devs will have the choice 
whether to deal with the same difficulties (without breaking compatibility 
with already existing projects) or just advice users to switch to 
PickleSerializer. It's just one line in your settings.py and has no 
inconvenience.

I can see what you mean about people complaining. But it would be 
mitigating the migration issues implied by switching to JSONSerializer. You 
are trading a few vocal complaints for a generalized struggle.

[...] that's what I'd call impact; the current impact is __only__ on [...]
>

The examples you mentioned (forms, admin) were significant improvements 
themselves, with big benefits to Django users. Switching the default 
session serializer to JSONSerializer is providing no benefit to any user. 
It's addressing a security problem (which is already documented) that only 
a few users have (can you provide a big^H^H^H list of users who use signed 
cookies but can't add a SESSION_SERIALIZER setting next to their 
SESSION_COOKIE_HTTPONLY and SESSION_COOKIE_SECURE settings?). 

I don't want to lose focus on my proposal. It's either to change the 
default to PickleSerializer or to mitigate the JSONSerializer issue 
supporting these data types:

   - datetime, timedelta objects (supported by DjangoJSONEncoder)
   - decimal objects (supported by DjangoJSONEncoder)
   - arbitrary binary strings (b'\xe8')
   - Geometry objects

This doesn't include Models or other objects which don't have any obvious 
serialization format.

As much as I'd hate to see (de)serialization code in views, I wouldn't 
consider a third option: a mechanism to provide custom serialization for 
other object types. I see it's already been discarded.

Davide

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Tom Evans]

On Wed, Sep 18, 2013 at 12:29 PM, Curtis Maloney
 wrote:
> I started working on a CacheManager for dealing with thread local cache
> instances, as was suggested on IRC by more than one person.
>

The problem that Florian identified was that recreating cache
instances each time get_cache() was called could be costly. Before you
go too far down the thread local route, could you verify that
retrieving cache objects from a thread local cache is in any way
faster than simply recreating them as demanded.

Cheers

Tom

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Florian Apolloner]

On Friday, September 20, 2013 10:24:00 AM UTC+2, Davide Rizzo wrote:
>
> - using the raw JSONEncoder by default is not offering any significant 
> security advantage over using an extended encoder. I feel like it's going 
> to discourage coders to use JSONSerializer at all.
>

Btw could it be that you are mixing out Encoder and Serializer? Or are they 
supposed to be the same, if not please add import names, so one knows which 
and from where you mean. Personally I don't see any improvement in using an 
extended encoder -- in the end it's just more work for us and people 
complaining why we don't support their $magical class. In most if not all 
cases storing full objects in the session is wrong; what we could have 
supported would be timestamps, but those are storable as utc seconds easily 
enough… Why would the current status be discouraging anyone?

But I believe this decision didn't give a realistic weight to the impact on 
> the community.
>

I still fail to see the issue; 3rd party projects have to adapt, this is 
why we have deprecation paths and accelerated paths for security related 
stuff. The net result is the same, at some point you will be forced to use 
a new feature (although in this case a bit sooner, but again: security and 
you can reenable the old default); eg newforms->forms, Model.Admin class to 
newadmin etc. And those last two literally affected everyone, that's what 
I'd call impact; the current impact is __only__ on people which do use the 
session (granted that's probably everyone) and did put complex data into 
the session. This pretty much narrows the list down to a percentage of the 
whole usergroup, when I audited my projects for this switch I had a few 
datetimes saved, although most of them saved them as integers already 
(which makes sense from a performance standpoint).

So all in all I think 3rd party authors will adapt without any problems 
since they are most of the time not affected, or they'll have to change a 
few lines of code… Can you provide a big list of 3rd party apps storing 
Models etc in the session?

Regards,
Florian

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: FormSetView and ModelFormSetView

[Stratos Moros]

On 20 Sep 2013, at 9:55, Russell Keith-Magee wrote:

On Fri, Sep 20, 2013 at 2:41 PM, Marc Tamlyn  
wrote:


This is partly because there's no obvious correct implementation of 
them ;)


Yes, I think these views should exist. But they go with the same body 
of
work as handling multiple forms, inline formsets etc. At present I 
have no
yet found the time to think about this problem, as a whole and come 
up with

a single consistent solution.

I'm not sure FormSetView *should* exist. I'd be a lot more inclined to 
look
at something like FormContainer -- a form-like container that can 
contain
multiple forms and formsets. There's a sample implementation on #18830 
in
the context of extending FormWizard to support combinations of form 
and

formset.

https://code.djangoproject.com/ticket/18830

If you had a form container, you wouldn't need a new generic view -- 
you

can just use FormView, and use the FormContainer as the form.

(I'd also like to rethink generics in general, but that's a whole 
other

conversation… and one that I need to internally progress from vauge
rambling to slightly coherent proposal… and then find time to work 
on :-)


Yours,
Russ Magee %-)



+1 on having a way to arbitrarily compose forms and formsets on django's 
core.


Having built ways to nest forms and formsets within forms, I'll have to 
agree with Andrew that having something like `forms.SubForm(MyForm)` or 
`forms.SubFormSet(MyFormSet)` would be a better api than having a 
generic view or an abstraction between views and forms (that's what I 
assume you mean with FormContainer).


Composing multiple forms or formsets by adding `nested_form = 
forms.SubForm(MyForm)` in the form definition seems like a natural 
extension of the Form api and presents a lot of benefits:


1. It is apparent to the api user that the parent form would maintain 
the same external api. `my_form.is_valid`, `my_form.save` on a 
ModelForm, `{{ my_form }}` in the template, etc. would still work and 
take into account the nested forms. Having a different object act as a 
form/formset container would mean that either the users would have to 
learn another api, or that the container would have to mirror the form 
api (in which case, it might as well be a form). This also means that 
(depending on the use case) you could add sub forms/formsets on your 
form and have your view and template code remain unchanged.


2. It also maintains the same internal api, since adding a form/formset 
and customising its validation would be the same as adding any other 
field. This also allows you to mix regular fields with sub 
forms/formsets.


3. It allows arbitrary composition of form/formsets. Since the container 
object would be a regular form, it could be used wherever a form could 
be used. This means that you could use a form containing a sub 
form/formset with formsets, form wizards, generic form views etc. 
without having to do any additional work. This would also trivially 
solve the formsets-within-formsets problem (my original use case) that a 
lot of people seem to be having trouble with (google "django nested 
formsets").


4. It opens the road for more intelligent ModelForms. This wouldn't be 
done automatically for backwards compatibility reasons, but having a 
well defined way to nest sub forms/formsets within forms could be 
extended to automatically create them for OneToOneFields and 
ManyToManyFields.


Having said all that, there are a few factors that would make the 
implementation and usage a bit tricky. In no particular order:


1. The Fields/Widget api is not well suited for `SubForm/Formset` 
fields. I could elaborate more on this, but the crux of the problem is 
that fields and widgets are used internally in a stateless manner, while 
forms and formsets need to keep track of a lot of state. That said, I 
think it could be done.


2. It requires modifications of `django.forms.Form` (and potentially of 
`django.forms.BoundField`, depending on the template api it would 
expose). This means that this couldn't be done in a third-party app as a 
proof of concept. My solution has been to create a custom Form subclass 
and inherit from it whenever I need the sub form/formset functionality, 
but this is incompatible with other apps that require you to inherit 
from their custom Form subclass (eg. floppyforms).


3. There are issues with saving sub forms/formsets. Saving an outer form 
with `commit=False` cannot really return an object that would save 
everything when its `save` method is called, due to the same orm 
limitations that has necessitated the `save_m2m` method. The optimal 
solution would be to solve this in the orm layer, but I have no idea if 
this is feasible. My solution is to create additional `save_forms` and 
`save_formsets` methods on the form instance, plus a fourth 
`save_related` method that just calls the other 3. The result is that 
the form's external api remains similar, but you have to call 
`save_related` instead of `save_m2m

Re: FormSetView and ModelFormSetView

[Marc Tamlyn]

Yes, I do think explicitly building each view like the views are built at
present is not the correct solution. By these views should exist I meant
more there should be a view which handles these cases, not necessarily does
the logic itself.

Russ - we should talk about this properly at some point, I think we have
similar ideas about where this should go. I've got some concepts banging
around in my head for gcbv2 but they're a bit unclear.

Andrew - you're right into that the cross dependencies of forms/formsets on
the page is definitely something to consider. This is probably something
which is pretty ugly away from the issue of class based views though.
On 20 Sep 2013 09:53, "Andrew Ingram"  wrote:

> Having basically built all of the views in question, I agree with Russell.
> By having multiple form classes in a view itself, you're essentially
> pulling validation logic out of the form and into the view where it doesn't
> belong. A view shouldn't be concerned with the specifics of validation, it
> should be concerned with what to do once you have the validated data.
>
> For example: I have a Form and a FormSet, I have a field on the form that
> is only required if the formset has zero rows. Conventional solutions
> involving having the form and formset on the view are all pretty ugly.
> Whereas if the form itself knows how to validated any "subforms", you get
> much better options.
>
> I'm not entirely sold on the concept of FormContainer, i'd learn more
> towards new fields like `forms.SubForm(MyForm)` or
> `forms.SubFormSet(MyFormSet)` (assuming such a thing is achievable). Then
> we get a nice a familiar API, and are able to do things on the parent form
> such as being able to define a clean_* method for subforms/sets.
>
>
> Andy
>
>
> On 20 September 2013 07:55, Russell Keith-Magee 
> wrote:
>
>>
>> On Fri, Sep 20, 2013 at 2:41 PM, Marc Tamlyn wrote:
>>
>>> This is partly because there's no obvious correct implementation of them
>>> ;)
>>>
>>> Yes, I think these views should exist. But they go with the same body of
>>> work as handling multiple forms, inline formsets etc. At present I have no
>>> yet found the time to think about this problem, as a whole and come up with
>>> a single consistent solution.
>>>
>> I'm not sure FormSetView *should* exist. I'd be a lot more inclined to
>> look at something like FormContainer -- a form-like container that can
>> contain multiple forms and formsets. There's a sample implementation on
>> #18830 in the context of extending FormWizard to support combinations of
>> form and formset.
>>
>> https://code.djangoproject.com/ticket/18830
>>
>> If you had a form container, you wouldn't need a new generic view -- you
>> can just use FormView, and use the FormContainer as the form.
>>
>> (I'd also like to rethink generics in general, but that's a whole other
>> conversation… and one that I need to internally progress from vauge
>> rambling to slightly coherent proposal… and then find time to work on :-)
>>
>> 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 django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: FormSetView and ModelFormSetView

[Andrew Ingram]

Having basically built all of the views in question, I agree with Russell.
By having multiple form classes in a view itself, you're essentially
pulling validation logic out of the form and into the view where it doesn't
belong. A view shouldn't be concerned with the specifics of validation, it
should be concerned with what to do once you have the validated data.

For example: I have a Form and a FormSet, I have a field on the form that
is only required if the formset has zero rows. Conventional solutions
involving having the form and formset on the view are all pretty ugly.
Whereas if the form itself knows how to validated any "subforms", you get
much better options.

I'm not entirely sold on the concept of FormContainer, i'd learn more
towards new fields like `forms.SubForm(MyForm)` or
`forms.SubFormSet(MyFormSet)` (assuming such a thing is achievable). Then
we get a nice a familiar API, and are able to do things on the parent form
such as being able to define a clean_* method for subforms/sets.


Andy


On 20 September 2013 07:55, Russell Keith-Magee wrote:

>
> On Fri, Sep 20, 2013 at 2:41 PM, Marc Tamlyn wrote:
>
>> This is partly because there's no obvious correct implementation of them
>> ;)
>>
>> Yes, I think these views should exist. But they go with the same body of
>> work as handling multiple forms, inline formsets etc. At present I have no
>> yet found the time to think about this problem, as a whole and come up with
>> a single consistent solution.
>>
> I'm not sure FormSetView *should* exist. I'd be a lot more inclined to
> look at something like FormContainer -- a form-like container that can
> contain multiple forms and formsets. There's a sample implementation on
> #18830 in the context of extending FormWizard to support combinations of
> form and formset.
>
> https://code.djangoproject.com/ticket/18830
>
> If you had a form container, you wouldn't need a new generic view -- you
> can just use FormView, and use the FormContainer as the form.
>
> (I'd also like to rethink generics in general, but that's a whole other
> conversation… and one that I need to internally progress from vauge
> rambling to slightly coherent proposal… and then find time to work on :-)
>
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is "transaction.atomic" in 1.6 supposed to work this way?

[Richard Ward]

>
> So you don't think that "one step of an atomic operation failing" is 
> reason to fail the atomic operation?  Doesn't sound intuitive to me.   
>
...
>
The concept of an "atomic" operation, even outside the context of DBMSs, is 
> pretty much the consistent throughout CS.
>
> If you are expecting the step could fail, then you should wrap it in a 
> sub-transaction - the very reason they exist.  Again, you have an atomic 
> operation [the insert] that may fail, so you want to gracefully handle it.
>

In my defense... as far as I was concerned I did gracefully handle it - I 
caught the exception in python. If my desired outcome is: ((A or B) then C) 
or ((A unless IntegrityError) then C) and A and B are atomic, then I don't 
see the need for a sub-transaction (If the DB allows such behavior) - I'm 
not firing A, B and C at the database blindly, I'm reacting to what the DB 
tells me about each statement's execution before sending the next. Either 
my whole block of code is executed as I intended, or there is a rollback. 
If I'm sending a batch of commands to the DB I can see how MySQL's behavior 
will cause pain, but given that I'm always using another language to send 
commands one by one to the db with the ability for my code to react, I'd 
not previously noticed that MySQL's behavior was odd.

Anyway, my point was that I think others are not unlikely to try this. If 
they do, its not so easy to tell what has gone wrong. I appreciate that 
Django can't deal with people trying really hard to break things, I just 
don't reckon I was trying that hard :)

I'll open a ticket about the docs later today.

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Default session data serializer doesn't support extended data types

[Davide Rizzo]

Hi Tim,

Indeed I looked at the comments in the ticket and pull request. I don't 
feel like these changes provide a significant security improvement:
- using JSONSerializer over PickleSerializer is only relevant if you are 
using any non-default configuration that allows session data to be 
tampered. Incidentally, the whole contrib.auth (project-default) mechanism 
is compromised in this case anyway, even if you use JSONSerializer.
- using the raw JSONEncoder by default is not offering any significant 
security advantage over using an extended encoder. I feel like it's going 
to discourage coders to use JSONSerializer at all.

Pushing the community, as you say it, is a decision with a rather big 
impact and carries some responsibility. I understand this has been 
discussed and I respect that the core developers agreed on a decision. But 
I believe this decision didn't give a realistic weight to the impact on the 
community.

Davide

On Thursday, September 19, 2013 6:23:56 PM UTC+2, Tim Graham wrote:
>
> Hi Davide,
>
> Did you take a look at the design decisions as described in the ticket and 
> pull request? We made these decisions in order to push the community toward 
> developing more secure apps and the transition isn't expected to be 
> painless. We had several core developers review the patch and discuss the 
> decisions. It seems like you are asking us to reconsider, but you haven't 
> presented anything we haven't discussed. Would you like me to address 
> anything specific?
>
> Tim 
>
> On Thursday, September 19, 2013 10:46:44 AM UTC-4, Davide Rizzo wrote:
>>
>> #20922  introduced the 
>> option to choose a custom session data serializer. The default option is to 
>> use the new JSONSerializer starting from 1.6, since using pickle would lead 
>> to a remote code execution vulnerability when session data is stored in 
>> cookies.
>>
>> While this can be considered a sensible security choice, it becomes 
>> inconvenient as the JSON encoder used by JSONSerializer is not the same 
>> used elsewhere in Django, as it only support basic data types: string, 
>> int/floats, booleans, nested dicts and lists, None.
>>
>> The inconvenience is breaking compatibility with all third party apps 
>> that rely on storing extended data types (such as those supported by 
>> DjangoJSONEncoder) with the default settings. Properly serializing datetime 
>> (possibly tz-aware) can be hard, and changing the default puts the burden 
>> on third party apps coders.
>>
>> They would have the option to either add two complexity layers (properly 
>> serializing/deserializing datetime objects, and not breaking compatibility 
>> with the previous versions of the same app), or to break compatibility with 
>> Django default settings.
>>
>> As an example of commonly used data types that can't be stored anymore 
>> with default settings:
>>
>>- datetime, timedelta objects (supported by DjangoJSONEncoder)
>>- decimal objects (supported by DjangoJSONEncoder)
>>- arbitrary binary strings
>>- Geometry objects
>>
>> I think the option of reverting the default to pickle should be also 
>> considered.
>>
>> [[I originally posted this as 
>> #21124, 
>> where it was closed as not a bug. What follows is the response I got, for 
>> reference:
>>
>> by timo (core developer)
>>
>> Thanks for your thoughts. I think most of the points you've raised were 
>> discussed during the implementation of this, either on the ticket 
>> (#20922) 
>> or on the linked pull request 
>> (or 
>> the documentation 
>> itself).
>>  
>> Could you please take a look at the discussion there if you haven't? If 
>> after reading that you still have disagreements, please raise the issue on 
>> django-developers rather than this ticket tracker. Thanks!
>>
>> Suggestions for documentations edits or additions would also be welcome.
>>
>> p.s. To address one of your points, one of the decisions was indeed to 
>> put the burden on third party app coders to serialize session data as 
>> simple data types like strings which would be compatible with JSON. We made 
>> this change to contrib.messages for example.
>> ]]
>>
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Curtis Maloney]

Yeah... simpler solution is simpler :)

--
C



On 20 September 2013 17:04, Florian Apolloner  wrote:

>
>
> On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote:
>>
>> I guess the remaining question to address is :  close()
>>
> Leave it as is I think.
>
>
>> Thinking as I type... it wouldn't hurt, also, to allow a cache backend to
>> provide an interface to a connection pool, so the manager can play friendly
>> with it.  If it doesn't have one, fall back to an instance-per-thread...
>> this would require still hooking request complete, but not so much for
>> "close" as "release".
>>
>
> If it can be added afterwards without to much issues, I prefer to leave
> APIs for connection pools out for now; since it will make the patch
> smaller, which makes it easier to merge.
>
> Florian
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: get_cache and multiple caches

[Florian Apolloner]

On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote:
>
> I guess the remaining question to address is :  close()
>
Leave it as is I think.
 

> Thinking as I type... it wouldn't hurt, also, to allow a cache backend to 
> provide an interface to a connection pool, so the manager can play friendly 
> with it.  If it doesn't have one, fall back to an instance-per-thread... 
> this would require still hooking request complete, but not so much for 
> "close" as "release".
>

If it can be added afterwards without to much issues, I prefer to leave 
APIs for connection pools out for now; since it will make the patch 
smaller, which makes it easier to merge.

Florian

-- 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.