Re: type-field model inheritance

Since multi-table-inheritance is the only kind of inheritance (apart from abstract/proxy) supported by Django's ORM, I don't know what other type of inheritance django_polymorphic would be referring to... As per my original post, I want to store everything in one table (all subclasses have

Re: type-field model inheritance

Hi Carl, > FWIW, django-model-utils [1] includes an InheritanceManager that > implements polymorphic queries in a single query via select_related. Ah, there goes my theory that I thought of it first :) And of course introspection of subclasses via the reverse OneToOne descriptors is perfect. --

Re: the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off

On Fri, Mar 4, 2011 at 10:24 AM, Viktor Kojouharov wrote: > > I'm testing my software with the new rc1 release of django 1.3, and I came > onto a particularly nasty problem. > I have a model which uses a Postgresql 'point' type, for which I've defined > a field as: >

Re: type-field model inheritance

Hi Simon, On Mar 4, 3:27 am, Simon Meers wrote: > +1 for better polymorphic support in Django core; it is a very common > problem which could do with an efficient and elegant solution. > Regarding efficiency, if you can keep track of your subclasses > effectively (potentially

Re: type-field model inheritance

Hi Craig, On Mar 4, 1:03 am, Craig de Stigter wrote: > It looks like django_polymorphic does what I want. I'm not yet sure why it > says it takes one query per type of model in a queryset. Unless it is > talking about multi-table inheritance, in which each type would require

Re: Problem due to contenttype cache

On Mar 4, 5:55 am, Rahul wrote: > When i ran test cases of multiple_databases model of regressiontests > then "test_generic_key_deletion" test case gave Error at the point > where it was trying to create Review object using "other" db, > but when i ran

Re: Brute force attacks

On Fri, 2011-03-04 at 17:22 -0500, Shawn Milochik wrote: > the thread referred to above discusses throttling, whereas the > "recommendation" provided to us by the auditors was user lockout > requiring administrator activity (human intervention) to unlock. This *creates* a denial of service

Re: Brute force attacks

do you guys know about django-axes? (http://code.google.com/p/django-axes/) it allows you to lock out IP or IP/User Agent combo on a given number of failures. On Fri, Mar 4, 2011 at 5:22 PM, Shawn Milochik wrote: > I have an immediate interest in this discussion. One of my

Re: Brute force attacks

I have an immediate interest in this discussion. One of my company's Django apps was recently subjected to an external risk assessment team audit. They found the fact that three invalid password attempts didn't lock out the user to be completely unacceptable. Granted, this is something that I

Brute force attacks

Hi all, I wanted to revisit a key security discussion. Brute force attacks are the 7th most prevalent attack by number of incidents in the Web Hacking Incidents Database (http://projects.webappsec.org/w/ page/13246995/Web-Hacking-Incident-Database), which tracks publicly disclosed breaches in web

Re: Storing language in session/cookie

2011/3/4 Mikołaj S. : > I know, but it just seems so obvious to me that I can't believe no one have > ever encountered this problem before - I felt like I should ask ;) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers"

Re: Storing language in session/cookie

I know, but it just seems so obvious to me that I can't believe no one have ever encountered this problem before - I felt like I should ask ;) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Storing language in session/cookie

I'm not familiar with that subsystem, but if what you say is correct, you should open a ticket. That sounds like a definite issue to me. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

the new SELECT DISTINCT query in 1.3 rc1, and how to turn it off

Hello, I'm testing my software with the new rc1 release of django 1.3, and I came onto a particularly nasty problem. I have a model which uses a Postgresql 'point' type, for which I've defined a field as: http://dpaste.com/472467/ I also have another model, which references this one with a

Storing language in session/cookie

Hi, I'd like to make a proposal of changing the way that current language is stored, at least, making this changeable by settings. The problem is that even for non-logged users their language is stored in session (if it's supported or in the cookie otherwise). That creates a session for every

Problem due to contenttype cache

When i ran test cases of multiple_databases model of regressiontests then "test_generic_key_deletion" test case gave Error at the point where it was trying to create Review object using "other" db, but when i ran "test_generic_key_deletion" test case only then it passed perfectly. When i narrowed

Re: type-field model inheritance

On 4 March 2011 17:03, Craig de Stigter wrote: > Hi guys > > Thanks for pointing those out. I knew I couldn't have been the first to want > this. I guess I just didn't know the right words to search for here. > It looks like django_polymorphic does what I want. I'm not yet