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 c

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 I have no > yet found t

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 "Django developers" group.

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 wit

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 always. As far as I can tell th

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 course; I actually s

Re: AbstractUser to get more abstract

On Fri, Sep 20, 2013 at 12:11 PM, Luke Sneeringer wrote: > > > Sent from my iPad > > On Sep 19, 2013, at 9:24 PM, Russell Keith-Magee > wrote: > > > On Fri, Sep 20, 2013 at 10:53 AM, wrote: > >> > Note that EmailUser *doesn't* have a Meta: swappable definition. There >> is nothing on this model

Re: AbstractUser to get more abstract

Sent from my iPad > On Sep 19, 2013, at 9:24 PM, Russell Keith-Magee > wrote: > > >> On Fri, Sep 20, 2013 at 10:53 AM, wrote: >> > Note that EmailUser *doesn't* have a Meta: swappable definition. There is >> > nothing on this model that says "I am swappable", or "I am an appropriate >> >

Re: AbstractUser to get more abstract

> On Sep 19, 2013, at 8:06 PM, Russell Keith-Magee > wrote: > > Note that EmailUser *doesn't* have a Meta: swappable definition. There is > nothing on this model that says "I am swappable", or "I am an appropriate > substitute for User". > But isn't that assuming your conclusion? The point

Re: AbstractUser to get more abstract

On Fri, Sep 20, 2013 at 10:53 AM, wrote: > > Note that EmailUser *doesn't* have a Meta: swappable definition. There > is nothing on this model that says "I am swappable", or "I am an > appropriate substitute for User". > > Ah, this is were the misunderstanding was. authtools does actually set > s

Re: AbstractUser to get more abstract

> Note that EmailUser *doesn't* have a Meta: swappable definition. There is nothing on this model that says "I am swappable", or "I am an appropriate substitute for User". Ah, this is were the misunderstanding was. authtools does actually set swappable on its replacement user, too[1]. The two d

Re: AbstractUser to get more abstract

On Fri, Sep 20, 2013 at 2:21 AM, Luke Sneeringer wrote: > But Django already has the mechanism to know not to install the model. > It's the "swappable" Meta option. That is what causes User not to be > installed if it is not used (contra my initial statement yesterday; I was > flat wrong). > > Rig

Re: AbstractUser to get more abstract

Hi Jorge, On Thu, Sep 19, 2013 at 11:45 PM, Jorge Cardoso Leitão wrote: > Hi all. > > I summarise the options with some of the issues raised, and I add my own > concern. > > > One option presented here is to have both models in d.c.auth. As pointed > out by Russell and others, this causes the pro

Re: AbstractUser to get more abstract

Hi Bruno, On Fri, Sep 20, 2013 at 1:26 AM, Bruno Ribeiro da Silva < cont...@brunoribeiro.org> wrote: > Hi, I develop applications in Django and I started to read the developer > mailing list and got interested by this topic about MailUser problem and I > want to add my 50 cents, sorry if I'm taki

Re: AbstractUser to get more abstract

Hi Aaron. On Fri, Sep 20, 2013 at 8:00 AM, Aaron Merriam wrote: > Russell, my reply there isn't meant to be confrontational and yet > re-reading it I can see it being easily interpreted as such. > No worries - I didn't read your response as confrontational, but I'll make sure I continue to not d

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

I feel compelled to comment here... On 20 September 2013 09:32, Richard Ward wrote: > > I don't think that what I was trying to do (continue using a transaction > after an insert failed) was too outlandish. I'm not demanding that Django > should allow me to do it (tho that would be nice), but I

Re: AbstractUser to get more abstract

Russell, my reply there isn't meant to be confrontational and yet re-reading it I can see it being easily interpreted as such. My intention is to ask whether there is something about swappable that I am missing. It seems to work the way I stated above but your statement seems to imply that th

Re: AbstractUser to get more abstract

> > However, if auth.User (or any other model for that matter) is set as > AUTH_USER_MODEL, nothing prevents EmailUser from being installed. > The current behavior of swappable is that if two models are swappable on the same settings value, only the one designated by the settings value will be

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

Thanks for the explanations. I wasn't aware that particular difference between PostgreSQL and MySQL (I've not done much with PostgreSQL). Perhaps I could have been clearer in my original post: Ansii is right about silence... when I call my_func the transaction.atomic decorator rolls back the tr

FormSetView and ModelFormSetView

Hi All What are the chances of adding FormSetView and ModelFormSetView classes to the standard set of generic views? I know its not to much effort to do it yourself, but it will help a lot with consistency across different Django applications. Currently there are multiple 3rd party versions of

Re: AbstractUser to get more abstract

On Thu, Sep 19, 2013 at 9:41 PM, Marc Tamlyn wrote: > The problem you've got here is how it knows to *not* install EmailUser. If > it's a model defined in d.c.auth.models, it will get installed, > irrespective of whether it is AUTH_USER_MODEL or not. This is where we have > to special case the ne

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

This is what nested atomics do. In effect savepoints are just creating another transaction inside the existing one (if my memories of Aymeric's talk are correct). On 19 Sep 2013 21:48, "Hannu Krosing" wrote: > On 09/19/2013 04:52 PM, Anssi Kääriäinen wrote: > > After some investigation it turns o

Re: AbstractUser to get more abstract

> > I'm not sure it was the intention in the design of swappable. I don't know the intended use of swappable, but this seems like exactly the type of thing that a 'swappable' model should be able to do. > However, we still have the issue of different forms, urls, views etc all > based off t

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

I think there is a case of talking past each other going on here. On Thursday, September 19, 2013 11:33:00 PM UTC+3, Aymeric Augustin wrote: > Nonetheless, in my opinion, the root cause of the perceived misbehavior is > that user code (not Django code) catches IntegrityError inside an atomic >

Re: AbstractUser to get more abstract

I think you'll find that at least the Authentication form is wrong as well - at least in the sense that it calls the field username and it doesn't validate as an email. Once we get better at html5 fields as well, it won't be the correct input type. Admin registration, the management commands, and

Re: AbstractUser to get more abstract

Whilst this works, I'm not sure it was the intention in the design of swappable. Clever though and it would allow the single-app approach. However, we still have the issue of different forms, urls, views etc all based off the changed model. Making these change automatically would be horrible. I s

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

On 09/19/2013 04:52 PM, Anssi Kääriäinen wrote: > After some investigation it turns out that this isn't about > IntegrityErrors at all. Instead the problem is that inside @atomic block > Model.save() uses @atomic(savepoint=False) internally. And > @atomic(savepoint=False) forces the outer atomic bl

Re: [GSoC] Composite fields once again

This sounds exciting. I can't wait for this to land in master. Thanks, Michal! On Sunday, June 2, 2013 10:22:36 AM UTC-4, Michal Petrucha wrote: > > Hello everyone, > > I'm happy to announce that throughout the summer I'll be officially > working on composite fields under the supervision of And

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

On 19 sept. 2013, at 16:52, Anssi Kääriäinen wrote: > After some investigation it turns out that this isn't about IntegrityErrors > at all. Instead the problem is that inside @atomic block > Model.save() uses @atomic(savepoint=False) internally. And > @atomic(savepoint=False) forces the outer a

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

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 dis

Re: AbstractUser to get more abstract

But Django already has the mechanism to know not to install the model. It's the "swappable" Meta option. That is what causes User not to be installed if it is not used (contra my initial statement yesterday; I was flat wrong). Right now, User has a meta option: swappable = 'AUTH_USER_MODEL'

Re: AbstractUser to get more abstract

> On Sep 19, 2013, at 11:33 AM, Aaron Merriam wrote: > > I and my colleague (gavinw...@gmail.com) have made some edits to the wiki to > clarify the purpose of authtools, and more accurately explain what the > 'authtools' approach would look like. If you previously have examined > 'option 2'

Re: AbstractUser to get more abstract

Hi, I develop applications in Django and I started to read the developer mailing list and got interested by this topic about MailUser problem and I want to add my 50 cents, sorry if I'm taking a completely wrong approach, since I never developed the internals of Django. But what if we just add a A

Re: AbstractUser to get more abstract

I and my colleague (gavinw...@gmail.com) have made some edits to the wiki to clarify the purpose of authtools, and more accurately explain what the 'authtools' approach would look like. If you previously have examined 'option 2', I would ask that you go and reread that section in the wiki. htt

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

Hi Davide, On Thursday, September 19, 2013 4:46:44 PM UTC+2, Davide Rizzo wrote: > > 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 d

Re: AbstractUser to get more abstract

Hi all. I summarise the options with some of the issues raised, and I add my own concern. One option presented here is to have both models in d.c.auth. As pointed out by Russell and others, this causes the problem on how to define the models such that they are not installed if they are not be

Default session data serializer doesn't support extended data types

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

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

After some investigation it turns out that this isn't about IntegrityErrors at all. Instead the problem is that inside @atomic block Model.save() uses @atomic(savepoint=False) internally. And @atomic(savepoint=False) forces the outer atomic block to roll back if errors happen. If I recall corre

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

2013/9/19 Anssi Kääriäinen > There is a definite disparency about what the code does and what the docs > say: > """ > If the block of code is successfully completed, the changes are committed > to the database. If there is an exception, the changes are rolled back. > """ > > If an exception is ca

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

There is a definite disparency about what the code does and what the docs say: """ If the block of code is successfully completed, the changes are committed to the database. If there is an exception, the changes are rolled back. """ If an exception is catched inside the block, then there should

Re: AbstractUser to get more abstract

The problem you've got here is how it knows to *not* install EmailUser. If it's a model defined in d.c.auth.models, it will get installed, irrespective of whether it is AUTH_USER_MODEL or not. This is where we have to special case the new model somehow so it is only installed if we are using it. Th

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

2013/9/19 Richard Ward > So what is the problem here? I assume it is one of: > >1. 'innocent_looking_function' is badly written: it should not be >catching IntegrityErrors under any circumstances (though that seems like a >valid thing to do), it should instead use something like get_

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

If the `innocent_looking_function` would use transactions. And thus handles the `IntegrityError by` issuing a rollback, just like `get_or_create` does ( https://github.com/django/django/blob/1.6b4/django/db/models/query.py#L360-L390 ). Do you see the same behaviour in `my_func`? -- Gert Mobile: +

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

We're building a site that needs to use transactions, and have been doing so against the 1.6 beta as 1.6 is nearly out and we thought it would be easier to use the new transaction api, but we came across an unexpected problem. Basically if you catch an IntegrityError and 'recover' from it, the