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
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 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
> 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
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
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
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 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, 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
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
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
> 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
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
13 matches
Mail list logo
