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

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

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

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

Re: FormSetView and ModelFormSetView

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

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

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

Re: FormSetView and ModelFormSetView

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

Re: get_cache and multiple caches

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

Re: get_cache and multiple caches

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

Re: get_cache and multiple caches

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. > >

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

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

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

> > 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

Re: FormSetView and ModelFormSetView

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

Re: FormSetView and ModelFormSetView

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,

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

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

Re: get_cache and multiple caches

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

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

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

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

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

Re: get_cache and multiple caches

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

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

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: Default session data serializer doesn't support extended data types

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 >

Re: get_cache and multiple caches

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

Re: get_cache and multiple caches

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

Re: get_cache and multiple caches

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,

Re: AbstractUser to get more abstract

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,

Re: AbstractUser to get more abstract

> 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

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

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:

Re: AbstractUser to get more abstract

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

Re: AbstractUser to get more abstract

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

Re: System check framework

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).

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

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.

System check framework

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]

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

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

Re: get_cache and multiple caches

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?

Re: AbstractUser to get more abstract

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'`

Re: AbstractUser to get more abstract

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

Re: AbstractUser to get more abstract

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. >

Re: System check framework

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

Performance Docs

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

Re: Performance Docs

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 >

AUTO: Mario Briggs is out of the office -

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

Re: Performance Docs

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