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
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
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
>
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
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
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
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'`
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
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]
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.
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 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
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:
> 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,
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,
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
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 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
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
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
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
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
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
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
>
> 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
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
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.
>
>
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
I guess the remaining question to address is : close()
It looks like it was added to appease an issue with memcached, which may or
may not still be an issue [comments in tickets suggest it was a design
decision by the memcached authors].
Thinking as I type... it wouldn't hurt, also, to allow a
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
Yes, I agree, that why I suggested filing a documentation ticket in my first
answer.
--
Aymeric.
> Le 20 sept. 2013 à 01:32, Richard Ward a écrit :
>
> I think the docs could be improved
--
You received this message because you are subscribed to the Google Groups
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
On 19 sept. 2013, at 23:38, Anssi Kääriäinen wrote:
> Here, another_obj.save() will succeed. But the transaction will be *always*
> rolled back, silently. I don't see any good reason not to error out when
> using a connection which is going to be rolled back in
On 19 sept. 2013, at 22:47, Hannu Krosing wrote:
> Actually you can use subtransactions in postgresql if you want to manage
> failed queries yourself
That's exactly what transaction.atomic does, on all supported databases.
I'm sorry if I sound like I need a transactions 101
40 matches
Mail list logo