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
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
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
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
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
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.
>
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
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
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?
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
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
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
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).
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
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
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 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
> 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
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
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
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
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 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
>
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
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
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
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 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 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 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
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,
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
>
> 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
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
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...
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
36 matches
Mail list logo