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 c
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...
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
tampere
>
> 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 expect
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
shou
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,
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, inl
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 tha
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 calle
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
JSONS
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 sec
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 is
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 r
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
>
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 c
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 st
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
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, Aar
> 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
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:
dateti
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
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 proj
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
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).
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 re
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] tha
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 emai
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?
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 sh
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
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.
>
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 t
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 opp
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
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 Mess
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 agr
36 matches
Mail list logo
