At the risk of bike-shedding this to death - if the current behavior
included the correct message (user can't access the admin) - would we
seriously consider a ticket asking to replace it with the current
"misleading/more secure" message, for security's sake?
On Wed, 16 Mar 2011 06:11:18 +0
> We haven't yet, but had been planning on exploring a way to mutate the
> existing class in most circumstances, but haven't
> dug into it too much yet.
I have and I use this monkey patch for now: https://gist.github.com/872145
--
You received this message because you are subscribed to the Googl
Hi Alexander,
I have seen this in my app, too. It still runs fast enough. But
I guess the django code could be optimized.
Thomas
On 15.03.2011 01:49, Alexander Schepanovski wrote:
> I was optimizing my django app and ran into this. My app was spending
> too much time cloning querysets. I looke
I would be nice if support for composite primary keys would be implemented as a
special case of general composite fields. There would be no need for new Meta
options:
class Foo(Model):
x = models.FloatField()
y = models.FloatField()
coords = models.CompositeField((x, y), db_index=Tru
On Mar 16, 10:14 am, Thomas Guettler wrote:
> Hi Alexander,
>
> I have seen this in my app, too. It still runs fast enough. But
> I guess the django code could be optimized.
>
I had a patch for this problem somewhere, but can't find it now.
Basically it added inplace() method to queryset, and a
On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote:
> I would be nice if support for composite primary keys would be implemented as
> a special case of general composite fields.
It's appealing, but the reality is that no existing back-end actually has such
an animal as a composite field. I
On Mar 16, 11:43 am, Christophe Pettus wrote:
> On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote:
>
> > I would be nice if support for composite primary keys would be implemented
> > as a special case of general composite fields.
>
> It's appealing, but the reality is that no existing back-e
On Mar 16, 2011, at 9:13 AM, Carl Meyer wrote:
> I'm not expressing an opinion one way or another on composite primary
> key syntax, but I don't agree here that a Django model "field" must
> map one-to-one to a database column.
That's fair, but a composite index lacks some of the characteristics
I am not currently involved in Django Development, but as someone new
to Django I can endorse increased standardization & documentation in
the area of project management & structuring. I have struggled to
figure out the right set up for our project(s). I have also tried to
grapple with coupling d
> I had a patch for this problem somewhere, but can't find it now.
> Basically it added inplace() method to queryset, and after that no
> cloning of the inner query class would happen. The outer QuerySet
> would still be cloned, but that is relatively cheap. This was to
> prevent usage of the old r
On Mar 15, 9:46 am, Russell Keith-Magee
wrote:
> On Fri, Mar 11, 2011 at 1:14 PM, Simon Litchfield wrote:
> > Who votes we should come up with a django-blessed 'official' default
> > project layout / directory structure?
>
> Sure -- no disagreement that it would be good to have some common
> gro
If we're talking about the lowest common denominator and keeping
things simple, this is what I think we'd have:
myapp1/
myapp2/
myproject/
-django.wsgi.sample
-manage.py
-management/
--commands/
---myproject_mycommand.py.sample
-media/
--myproject/
---readme.txt
-models.py
-settings.py
-static/
--
On Mar 17, 3:11 am, Alexander Schepanovski wrote:
> Can you find that patch and post somewhere?
> If not still thanks for this idea.
Unfortunately, no. Gone with my old laptop.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
13 matches
Mail list logo
