Re: .save_m2m() failing with multi-database error

2011-09-26 Thread Greg Turner
FWIW Ben, I had the same error, but under different circumstances
(your message below is the top google result for the error!). For me,
the problem was caused by a custom save() method in the model not
calling super().save(). Did you omit such a method in your gist.github
models?

On 6 September 2011 17:26, Ben Standefer  wrote:
>
> I think I might have found an issue related 
> to https://code.djangoproject.com/ticket/14849.  The last comment says to 
> please email the django-dev group if there are any questions about the 
> ticket, so here I am.  I've done my best to provide a complete test case.
> I have an Event model with property 'times', which is a ManyToManyField to an 
> EventTime model.  https://gist.github.com/c7d8319df96f5eb22cf3
> I am processing data from a POST request with a ModelForm on Event, with a 
> custom field and widget: https://gist.github.com/653adb9b0ecbcc823339  The 
> widget takes a few POST fields and generates a set of date ranges as a list 
> of tuples [(, ), (, )...].  The to_python() method of 
> the custom field takes the date ranges and returns a list of EventTime 
> objects.
> When I try to .save_m2m() the form (test case 
> here: https://gist.github.com/6da4f69ade9bc7dc5b3c) I get...
> ValueError: Cannot add "": instance is on 
> database "default", value is on database "None"
>
> This looks it might be an issue with the new multi-database stuff.  I could 
> also be misunderstanding something, but after scouring the documentation for 
> several hours I don't see anything implying that this wouldn't work.  I 
> suspect the unusual thing I'm doing is creating instances of a Django model 
> within my field's to_python() method.  Most of the existing fields use 
> to_python() to cast to datetime or Decimal.  Is it not possible to convert 
> value(s) into instances of Django models?
> Thanks for your help.
> -Ben Standefer
> -Ben
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/uVcisHlDAzkJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.



--

Dr Greg Turner
Director, Technical Information Architect
the Interaction Consortium
http://interaction.net.au
Phone: +61 2 8060 1067
skype: gregturner
Follow us on twitter:
@theixc
@gsta
Be green! Read from the screen.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: User.objects.active() support.

2011-09-26 Thread Prometheus
On Sep 25, 8:02 am, tWoolie 
wrote:
> I never saw that ticket. I've been looking at it purely from the
> perspective of trying to inject it into the model in my app to get
> around doing expensive filtering in my template.
> I see Jacob's point that saving a few chars in python is not worth it
> for the cost of having to read docs to figure out what it does, but
> this would be a fantastic thing to have in templates where there is no
> way to specify filtering.

Hello,

I believe for this purpose, the Proxy models feature would be the
perfect solution, please see: 
https://docs.djangoproject.com/en/1.3/topics/db/models/#proxy-models

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: API for introspecting models

2011-09-26 Thread Mathieu AGOPIAN
(That's when somebody jumps into the conversation and feel as if he's half 
naked wearing dirty underwear)

Hello,

just FYI, I've hacked a few lines of code that I use to have a simple way to 
access all the fields on a model (including m2m):

https://github.com/magopian/django-inspect-model

I'd love to have feedback on this piece of crap^W code if you do have any 
use of it but feels it should be improved.

The code that inspects is in 
https://github.com/magopian/django-inspect-model/blob/master/inspect_model/utils.py
 
and uses the "inspect" module from the stdlib.

Mathieu

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/9c5d7X8p-_IJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Revisiting proxied SSL headers

2011-09-26 Thread Tom Evans
On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant  wrote:
>
> I'm happy to be proved wrong, of course. Apache is very popular, though,
> so if its hard in Apache, it could be said to be hard full stop.
>

  RequestHeader unset X-Forwarded-Protocol

Not precisely what I'd call hard.

>From a-business-that-uses-this-sort-of-stuff POV, we don't really mind
if this is fixed in Django at all. A lot of the enterprise bits that
our architecture needs (SetRemoteAddrFromForwardedFor, SSL middleware)
was either missing, or crippled with no intention to fix it
(SetRemoteAddrFromForwardedFor couldn't handle being behind multiple
proxies and was finally dumped).

It was pointed out to us that what we do is not particularly like the
majority of users, so we have been maintaining our own middleware
classes that updates or monkey patches the request object with the
appropriate info.

I suppose it is analogous to DB routers. Django doesn't provide
routers to handle the common ways to scale a database, but they are
simple enough to write for your specific setup. There is a simple way
to add your own fixups to requests, and it works, so we don't need to
burden the core or contrib with it.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Revisiting proxied SSL headers

2011-09-26 Thread Luke Plant
On 26/09/11 12:45, Tom Evans wrote:
> On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant  wrote:
>>
>> I'm happy to be proved wrong, of course. Apache is very popular, though,
>> so if its hard in Apache, it could be said to be hard full stop.
>>
> 
>   RequestHeader unset X-Forwarded-Protocol
> 
> Not precisely what I'd call hard.

I am indeed happy to have been proved wrong :-) ... if slightly
embarrassed...

I suppose we should check that this definitely works in conjunction with
mod_proxy and whichever module it is that sets X-Forwarded-Protocol/Ssl.

> I suppose it is analogous to DB routers. Django doesn't provide
> routers to handle the common ways to scale a database, but they are
> simple enough to write for your specific setup. There is a simple way
> to add your own fixups to requests, and it works, so we don't need to
> burden the core or contrib with it.

Given the security problems of getting HttpRequest.is_secure() wrong
either way, and the common solution to this particular problem, I think
it is better to have support in the core for this.

Luke

-- 
"I regret I wasn't born with opposable toes." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



get_field_display: Django needs a template filter to allow get_field_display for a dynamic field name

2011-09-26 Thread Ivan Kharlamov


There is often a need to write model-independent Django templates. By
now, the only field name-dependent attribute in Django templates is
get_field_display, because the particular field names must be
hardcoded for each model.

What I propose is a universal filter which should provide human-
readable value for a field of any type.

For example, like this:



{% for item in query %}



{% for field in fields %}

{{item|human_readable:field}}

{% endfor %}



{% endfor %}



I'm talking about something like this, but secure against exposing
_meta attributes:

def human_readable(value, arg):
if hasattr(value, 'get_' + str(arg) + '_display'):
return getattr(value, 'get_%s_display' % arg)()
elif hasattr(value, str(arg)):
if callable(getattr(value, str(arg))):
return getattr(value, arg)()
else:
return getattr(value, arg)
else:
try:
return value[arg]
except KeyError:
return settings.TEMPLATE_STRING_IF_INVALID

Here's the corresponding ticket: https://code.djangoproject.com/ticket/16034

Best regards,
Ivan Kharlamov

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Revisiting proxied SSL headers

2011-09-26 Thread Cal Leeming [Simplicity Media Ltd]
Just my two cents worth, but I think something like this is such a 'per case
basis', that it probably shouldn't be included in the core.

Unless you can guarantee that all web application servers/load balancers are
going to correctly handle the header out of the box (i.e. inject/strip where
necessary), then there's no way this could be "securely" introduced.

The reason I say per case basis, is because we've had to implement this same
middleware ourselves into multiple clients, all of which had to be slightly
different due to the handling of the SSL header at the load balancer.

Cal

On Mon, Sep 26, 2011 at 1:02 PM, Luke Plant  wrote:

> On 26/09/11 12:45, Tom Evans wrote:
> > On Sat, Sep 24, 2011 at 9:28 PM, Luke Plant 
> wrote:
> >>
> >> I'm happy to be proved wrong, of course. Apache is very popular, though,
> >> so if its hard in Apache, it could be said to be hard full stop.
> >>
> >
> >   RequestHeader unset X-Forwarded-Protocol
> >
> > Not precisely what I'd call hard.
>
> I am indeed happy to have been proved wrong :-) ... if slightly
> embarrassed...
>
> I suppose we should check that this definitely works in conjunction with
> mod_proxy and whichever module it is that sets X-Forwarded-Protocol/Ssl.
>
> > I suppose it is analogous to DB routers. Django doesn't provide
> > routers to handle the common ways to scale a database, but they are
> > simple enough to write for your specific setup. There is a simple way
> > to add your own fixups to requests, and it works, so we don't need to
> > burden the core or contrib with it.
>
> Given the security problems of getting HttpRequest.is_secure() wrong
> either way, and the common solution to this particular problem, I think
> it is better to have support in the core for this.
>
> Luke
>
> --
> "I regret I wasn't born with opposable toes." (Calvin and Hobbes)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: get_field_display: Django needs a template filter to allow get_field_display for a dynamic field name

2011-09-26 Thread Cal Leeming [Simplicity Media Ltd]
Ivan,

I completely agree that it would be useful to have something like this, as I
have some up against this *exact* same problem in the past.

However, when I raised it as an issue on IRC - the only response I got was
"stop putting your application logic into the templates" lol.

So, although I'm +1 on this, I suspect there may be others who would
strongly disagree with having it as part of the core.

Cal

On Mon, Sep 26, 2011 at 1:01 PM, Ivan Kharlamov wrote:

>
>
> There is often a need to write model-independent Django templates. By
> now, the only field name-dependent attribute in Django templates is
> get_field_display, because the particular field names must be
> hardcoded for each model.
>
> What I propose is a universal filter which should provide human-
> readable value for a field of any type.
>
> For example, like this:
>
> 
>
>{% for item in query %}
>
>
>
>{% for field in fields %}
>
>{{item|human_readable:field}}
>
>{% endfor %}
>
>
>
>{% endfor %}
>
> 
>
> I'm talking about something like this, but secure against exposing
> _meta attributes:
>
> def human_readable(value, arg):
>if hasattr(value, 'get_' + str(arg) + '_display'):
>return getattr(value, 'get_%s_display' % arg)()
>elif hasattr(value, str(arg)):
>if callable(getattr(value, str(arg))):
>return getattr(value, arg)()
>else:
>return getattr(value, arg)
>else:
>try:
>return value[arg]
>except KeyError:
>return settings.TEMPLATE_STRING_IF_INVALID
>
> Here's the corresponding ticket:
> https://code.djangoproject.com/ticket/16034
>
> Best regards,
> Ivan Kharlamov
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Revisiting proxied SSL headers

2011-09-26 Thread Carl Meyer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote:
> Unless you can guarantee that all web application servers/load balancers
> are going to correctly handle the header out of the box (i.e.
> inject/strip where necessary), then there's no way this could be
> "securely" introduced. 

The proposal is not to do anything automatically or by default, but to
require the user to explicitly set what header to look for, with
documentation warning them that they should only do this if they know
that the header is always set by their proxy.

I agree with Luke and Paul that support for this should be in core - as
they've discussed, the status quo is in itself a security problem. And
while fixing it with a custom middleware is certainly possible, it
requires monkey-patching the request.is_secure() method. Anytime we have
to tell a sizable percentage of our users "you really should add this
custom code to your project that monkeypatches Django core" it's a
pretty strong signal that core should provide better hooks instead.

> The reason I say per case basis, is because we've had to implement this
> same middleware ourselves into multiple clients, all of which had to be
> slightly different due to the handling of the SSL header at the load
> balancer.

Can you be more specific here? The only implementation differences that
I can imagine would be which header is checked, and which value is
expected to indicate SSL vs non-SSL. The proposed hook (currently
implemented in django-secure) already accounts for this variation by
requiring the user to explicitly specify the header and value that
should indicate an SSL request.

Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AqrMACgkQ8W4rlRKtE2dxmwCfRf+gXWLvm/Bup6r0ySJ0qVVU
luMAmwd5XT98WU/kIWLhbUy8NA3aPy7K
=AS+A
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Revisiting proxied SSL headers

2011-09-26 Thread Cal Leeming [Simplicity Media Ltd]
On Mon, Sep 26, 2011 at 5:39 PM, Carl Meyer  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/26/2011 06:16 AM, Cal Leeming [Simplicity Media Ltd] wrote:
> > Unless you can guarantee that all web application servers/load balancers
> > are going to correctly handle the header out of the box (i.e.
> > inject/strip where necessary), then there's no way this could be
> > "securely" introduced.
>
> The proposal is not to do anything automatically or by default, but to
> require the user to explicitly set what header to look for, with
> documentation warning them that they should only do this if they know
> that the header is always set by their proxy.
>

Ah - in that case (is it has to be configured by the user first, and doesn't
take any assumptions) then that would be much better). I thought you meant a
patch to make this "just work - out of the box".


>
> I agree with Luke and Paul that support for this should be in core - as
> they've discussed, the status quo is in itself a security problem. And
> while fixing it with a custom middleware is certainly possible, it
> requires monkey-patching the request.is_secure() method. Anytime we have
> to tell a sizable percentage of our users "you really should add this
> custom code to your project that monkeypatches Django core" it's a
> pretty strong signal that core should provide better hooks instead.
>
> > The reason I say per case basis, is because we've had to implement this
> > same middleware ourselves into multiple clients, all of which had to be
> > slightly different due to the handling of the SSL header at the load
> > balancer.
>
> Can you be more specific here? The only implementation differences that
> I can imagine would be which header is checked, and which value is
> expected to indicate SSL vs non-SSL. The proposed hook (currently
> implemented in django-secure) already accounts for this variation by
> requiring the user to explicitly specify the header and value that
> should indicate an SSL request.
>

Yeah - the thing you mentioned above about forcing the user to configure the
exact header tackles this point.

The problem I had previously, was that some load balancers don't forcibly
send or strip certain SSL offloading headers (such as X-Forwarded-Proto),
which could result in the user being able to trick the web application into
thinking it's in HTTPS, when it's not. But this isn't an issue if it's
"configured on demand".


>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6AqrMACgkQ8W4rlRKtE2dxmwCfRf+gXWLvm/Bup6r0ySJ0qVVU
> luMAmwd5XT98WU/kIWLhbUy8NA3aPy7K
> =AS+A
> -END PGP SIGNATURE-
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: confusing things in Trac UI (was: Design decision for #1625...)

2011-09-26 Thread Brian Neal
On Sep 20, 4:16 pm, Carl Meyer  wrote:
>
> Yeah, this is confusing in our Trac UI. The "accept" radio button at the
> bottom assigns the ticket to you, it doesn't actually do anything with
> the triage state. To change the ticket from DDN to Accepted you'd use
> the dropdown next to "Triage Stage" up in the box above.
>
> I'd be in favor of just removing that "accept" radio button if it isn't
> hard to do; doesn't do anything you can't do with the "reassign" option,
> just gets confused with the triage state.
>

In a vanilla Trac install, we've (my company) always had the person
assigned to the ticket hit "accepted" when he/she actually starts
working on the ticket. It is used to indicate that the assigned person
is actively working on the ticket. I'm not arguing it one way or
another with respect to Django usage, I'm just explaining what I think
the purpose of that state is in an out-of-the-box Trac install.

BN

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: confusing things in Trac UI (was: Design decision for #1625...)

2011-09-26 Thread Florian Apolloner
Hi,

On Monday, September 26, 2011 9:06:47 PM UTC+2, Brian Neal wrote:
>
> I'm not arguing it one way or 
> another with respect to Django usage, I'm just explaining what I think 
> the purpose of that state is in an out-of-the-box Trac install. 
>

Jupp, that's the state now -- sadly code.djangoproject.com uses trac for 
ages already and as such we do have the old workflow as described here: 
http://trac.edgewall.org/wiki/TracWorkflow 

The new work flow of trac 0.11 separates accepting from assigning; see the 
second image on the linked page above. We could also modify that workflow 
and add all our Triage states completely into this work flow (see 
http://trac.edgewall.org/wiki/WorkFlow/Examples for some examples of work 
flows).

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/oUX_tTUboE0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



prefetch_related - new feature suggestion

2011-09-26 Thread Luke Plant
Hi all,

I finally got fed up with the common performance problem of ending up
doing O(n) DB queries when you need the (many) related objects of a list
of objects, and did something about it:

https://code.djangoproject.com/ticket/16937

I'm pretty sure the concept is something desirable, the problem is the
implementation.

It is much uglier than I'd like, but I think the current way that
QuerySets/Managers/related managers interact make this inevitable.

The current behaviour also makes any kind of 3rd party monkey patching
solution extremely hard. For example, the related object descriptors
make it pretty hard to decorate instances of the queryset with some
proxy objects, because they intercept any assignment of attributes of
the same name. (i.e. if you have foo.bar_set, you can't do foo.bar_set
== some_precalculated_objects as a performance hack). And the way the
descriptors work mean that you get new manager objects (even new manager
*classes*) every time you access the property, and this really works
against any kind of monkey patching.

If you want to implement this outside core, and you don't want to change
templates and other code, I think you'd have to create a proxy for the
entire model instance, and I imagine it would be a total pain.

So, given how common this performance problem is, and how hard it is to
implement outside core, I think we should consider even an ugly
implementation. I think it is also inevitable that it is going to
involve QuerySet/related managers hacking each other's internals, or
duplicating to some extent. In my implementation, I put most of the
ugliness into QuerySet, and a few hooks into related managers. It might
be possible to clean it up a bit.

There is also a fairly nasty use of .extra() which is needed so that
after we retrieve M2M related objects in bulk we know which row on the
primary table they refer to.

I've got tests and docs in the patch on the ticket. I would say it is
more than proof-of-concept at this stage, but probably less than
finished patch - I may have forgotten some cases that we need to cover.

Feedback welcome!

Regards,

Luke

-- 
"I spilled spot remover on my dog. Now he's gone." (Steven Wright)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: prefetch_related - new feature suggestion

2011-09-26 Thread Alex Gaynor
On Mon, Sep 26, 2011 at 9:50 PM, Luke Plant  wrote:

> Hi all,
>
> I finally got fed up with the common performance problem of ending up
> doing O(n) DB queries when you need the (many) related objects of a list
> of objects, and did something about it:
>
> https://code.djangoproject.com/ticket/16937
>
> I'm pretty sure the concept is something desirable, the problem is the
> implementation.
>
> It is much uglier than I'd like, but I think the current way that
> QuerySets/Managers/related managers interact make this inevitable.
>
> The current behaviour also makes any kind of 3rd party monkey patching
> solution extremely hard. For example, the related object descriptors
> make it pretty hard to decorate instances of the queryset with some
> proxy objects, because they intercept any assignment of attributes of
> the same name. (i.e. if you have foo.bar_set, you can't do foo.bar_set
> == some_precalculated_objects as a performance hack). And the way the
> descriptors work mean that you get new manager objects (even new manager
> *classes*) every time you access the property, and this really works
> against any kind of monkey patching.
>
> If you want to implement this outside core, and you don't want to change
> templates and other code, I think you'd have to create a proxy for the
> entire model instance, and I imagine it would be a total pain.
>
> So, given how common this performance problem is, and how hard it is to
> implement outside core, I think we should consider even an ugly
> implementation. I think it is also inevitable that it is going to
> involve QuerySet/related managers hacking each other's internals, or
> duplicating to some extent. In my implementation, I put most of the
> ugliness into QuerySet, and a few hooks into related managers. It might
> be possible to clean it up a bit.
>
> There is also a fairly nasty use of .extra() which is needed so that
> after we retrieve M2M related objects in bulk we know which row on the
> primary table they refer to.
>
> I've got tests and docs in the patch on the ticket. I would say it is
> more than proof-of-concept at this stage, but probably less than
> finished patch - I may have forgotten some cases that we need to cover.
>
> Feedback welcome!
>
> Regards,
>
> Luke
>
> --
> "I spilled spot remover on my dog. Now he's gone." (Steven Wright)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
I'm not a fan of this, for a few reasons, firstly: because it feels wrong
for a QuerySet to execute multiple queries.  This isn't a deal breaker, just
something that struck my conceptually initially.  Second I disagree that
it's difficult to do outside of core, it's not as easy as it ought to be,
but it's very possible (citation: I've done it :)).  Finally (for now ;)) it
doesn't feel right for something inside core to have caveats like "only
works if you use .all()", there's a very good technical reason for this, but
something about it is irking me the wrong way.

Needs more thought by me'ly yours,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: prefetch_related - new feature suggestion

2011-09-26 Thread Luke Plant
On 27/09/11 03:23, Alex Gaynor wrote:

> I'm not a fan of this, for a few reasons, firstly: because it feels
> wrong for a QuerySet to execute multiple queries.  This isn't a deal
> breaker, just something that struck my conceptually initially.  Second I
> disagree that it's difficult to do outside of core, it's not as easy as
> it ought to be, but it's very possible (citation: I've done it :)).

Would you like to share your solution? I found it pretty difficult to
come up with anything that:

1) could be done on a per-query basis and
2) didn't require changes to the code that would use the QuerySet
objects i.e. fully API compatible.

The one avenue I didn't explore yet was proxying the entire model
instance, which I'm sure would work, but could have lots of annoying
corner cases with Python magic methods etc.

Luke


-- 
"I spilled spot remover on my dog. Now he's gone." (Steven Wright)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



We're a group of students at UC Berkeley looking to contribute to Django

2011-09-26 Thread jaminw
Hi all,

We're a a group of students at UC Berkeley taking an open source class and 
we've decided to contribute to Django. 

We looked at the bug tracker but it seems a little disorganized and some of 
the easier bug reports are kinda trivial.

Is there any suggestions on how do we start?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: We're a group of students at UC Berkeley looking to contribute to Django

2011-09-26 Thread Alex Gaynor
On Mon, Sep 26, 2011 at 11:10 PM, jaminw  wrote:

> Hi all,
>
> We're a a group of students at UC Berkeley taking an open source class and
> we've decided to contribute to Django.
>
> We looked at the bug tracker but it seems a little disorganized and some of
> the easier bug reports are kinda trivial.
>
> Is there any suggestions on how do we start?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Hi.

First of all, we're glad you're looking to contribute to Django!  It's true,
our bug tracker has a lot of stuff in it, which is often confusing to
newcomers, any ways we could improve this are welcome.  There's various
documentation in our repository on what the exact process for contribution
is (https://docs.djangoproject.com/en/dev//internals/contributing/).  The
most important thing (IMO), is finding something you care about, whether
that's the ORM, the template language, forms, the admin, or anything in
between, working on something you find interesting, maybe something you like
using in Django, or that you don't like so much, makes the process of
contributing to Django significantly more awesome.

Hope that answers some of your questions,
Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: API for introspecting models

2011-09-26 Thread Mathieu AGOPIAN
Hello (again),

seems my previous message got eaten up, so I'll try a repost :

I've done a small app that I use to inspect models, it lives here: 
https://github.com/magopian/django-inspect-model

I'm afraid this isn't rocket science, and is probably very ugly. I'm using 
the "inspect" module from the python stdlib.

Please feel free to comment on my piece of crap^Wcode and let me know if 
there's anything that could help or if I need to tweak/modify anything to 
make it useful.

Regards

Mathieu

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/p5usIzkHPjAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: We're a group of students at UC Berkeley looking to contribute to Django

2011-09-26 Thread Alec Taylor
Great to hear you're getting involved!

Some things I'd like implemented in DJango involve reducing
build-setup environment and expanding project uses to the CMS markets
by incorporated DJango project distribution+setup.

For starters, I was thinking 3 installers (exe,rpm,deb) and a shell
script (sh), but eventually building a small website around DJango for
setups.

Steps
- Download python
- Install python (set location)
- Download django
- Install django (set location + perhaps select db info?)
- Download project (perhaps pick from list?)
- Install project
- Option to run project + run readme

I'm currently too distracted by the actual project I want to
distribute to do this on my own.

If a few of you are interested though, I can give you tips+guidance to
get started. :]

All the best,

Alec Taylor

On Tue, Sep 27, 2011 at 1:10 PM, jaminw  wrote:
> Hi all,
> We're a a group of students at UC Berkeley taking an open source class and
> we've decided to contribute to Django.
> We looked at the bug tracker but it seems a little disorganized and some of
> the easier bug reports are kinda trivial.
> Is there any suggestions on how do we start?
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/p2sX1LUo6K0J.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.