Re: [GSOC] Weekly update

[Josh Smeaton]

Excellent work, well done. I have a couple of questions/ideas though.

1. The use of bit flags irks me. Would it be possible just to use numerous 
keyword arguments to the new get_fields ?
2. Since you've reduced the API to effectively two functions (get_fields, 
get_field), is it still necessary to contain those methods on an inner 
object? Can't the new methods live directly on the model? If they can't be 
put directly on the model for some reason, I would consider a better name 
than "meta". I can't think of a reason that the name meta should be used 
other than history. If you were to think about the purpose of the API 
without the associated history, what would you call it?

log = Log.objects.get(pk=1)
log.get_fields(concrete=True, m2m=True, related=True)

log.get_field('log_level') # we're being explicit about the field name, no 
need for options


Thoughts?

I'll take a better look at the PR and see if I can offer anything with 
regards to your performance optimisations.

Josh 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7496ef6d-4e88-41f4-b2b8-1bd2efa96aea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Curtis Maloney]

Can I ask as a favour to future works that you record all the performance
tuning approaches you use?

Many of these will be obvious to seasoned Python programmers, but some of
them won't be, and it would be nice to have a catalogue of "things to look
out for" to apply to critical paths in Django.

--
Curtis



On 5 July 2014 20:11, Josh Smeaton  wrote:

> Excellent work, well done. I have a couple of questions/ideas though.
>
> 1. The use of bit flags irks me. Would it be possible just to use numerous
> keyword arguments to the new get_fields ?
> 2. Since you've reduced the API to effectively two functions (get_fields,
> get_field), is it still necessary to contain those methods on an inner
> object? Can't the new methods live directly on the model? If they can't be
> put directly on the model for some reason, I would consider a better name
> than "meta". I can't think of a reason that the name meta should be used
> other than history. If you were to think about the purpose of the API
> without the associated history, what would you call it?
>
> log = Log.objects.get(pk=1)
> log.get_fields(concrete=True, m2m=True, related=True)
>
> log.get_field('log_level') # we're being explicit about the field name, no
> need for options
>
>
> Thoughts?
>
> I'll take a better look at the PR and see if I can offer anything with
> regards to your performance optimisations.
>
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7496ef6d-4e88-41f4-b2b8-1bd2efa96aea%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSAnunv9t4GkJC7jha3Qy773eVDSL%2B9TACRAjqXDdyLuCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Querying across FK produces too many OUTER JOINs (1.6) or FieldError (1.7)

[Jon Dufresne]

On Fri, Jul 4, 2014 at 7:44 PM, Anssi Kääriäinen
 wrote:
> I wasn't able to reproduce this - are you sure the query is exactly the same
> both on 1.6 and 1.7? Are models are set up correctly before generating the
> query? If after double-checking you still get the error, could you post a
> sample project somewhere?

I have created a test repository at


Upon recreating the test scenario, I have discovered that this is a
false alarm. In my original testing I didn't add my app with the
models to the list of INSALLED_APPS. Without this step (which is
clearly a bug in my test application) the FieldError occurs.

Testing, I see that the OUTER JOIN in 1.6 did in fact change to an
INNER JOIN in 1.7! Thanks for that! Sorry about the confusion and my
mistakes.

Cheers,
Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b4CEwX%3DZhW-bzoU59F8T4%2BtWWtrsCvfxjsiVegL%2BVy2YQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.