Re: Why not Single Table Inheritance?

2014-06-11 Thread Florian Apolloner


On Wednesday, June 11, 2014 2:16:06 AM UTC+2, Craig de Stigter wrote:
>
> I reserve judgment on whether STI should be included in core. It works 
> fine in a third-party app. Some better support for it in core would be 
> helpful, since currently I'm relying on some unsupported stuff that the 
> core devs could decide to break at any time.
>

We'll happily add hooks to make support easier, patches welcome.

Cheers,
Florian 

-- 
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/77aff80c-2a47-4c01-b59a-5576d9b210fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for function application in ORDER BY

2014-06-11 Thread Shai Berger
On Tuesday 10 June 2014 02:48:14 Josh Smeaton wrote:
> > However, I think having some special case code in filter(), annotate()
> 
> and anything else that takes expressions would be OK
> 
> I strongly disagree with this. Expressions are context insensitive at the
> moment, which means they can be used anywhere. If we start externalising
> behaviour based on the context of use, it'll lead us to some very confusing
> code and a tonne of special cases.

+1 Josh.

However, per the __neg__ issue, I think you're heading in the wrong direction: 
ordering shouldn't be a feature of an expression, because an expression with 
ordering cannot be used the same way: It cannot be combined with other 
expressions (because the ordering of the result is intuitively ambiguous), it 
shouldn't be used for comparisons etc.

So, I think, in terms of implementation (and I'm doing this in horrible style, 
without looking at your actual patches -- sorry if I'm way off), once you apply 
ordering to an expression, you should get a different-typed object. Indeed, a 
wrapper would be suitable, but it should no longer be an expression IMO.

And in terms of API as well -- the hints should be clear that this is different 
from normal expression creation. Both "-Expression" and "Desc(Expression)" 
look like other expressions, so I think they're suboptimal. I'd prefer 
something like "Expression.desc()" which reads nicely:

Model.objects.filter(...).order_by( F('fld_a').desc(), 
F('fld_b')).asc() )
Model.objects.filter(...).order_by( (F('fld_a')+F('fld_b')).desc() )

(desc as a property instead of method would read nicer but feels less "right" 
as Python).

My 2 cents,

Shai.

-- 
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/201406111357.36512.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.


Solving the select+1 problem.

2014-06-11 Thread Jonathan Slenders
The "select+1" problem is a problem that people often face in Django.
Usually, something like select_related solves it, but I don't think that's 
always possible.

Facebook released Haxl today and there's an example of their apprach to the 
problem.
https://github.com/facebook/Haxl/tree/master/example/sql

I don't know enough Haskel to understand this code, but it could contain 
some very nice ideas that apply to our ORM as well.

Cheers,
Jonathan

-- 
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/f81a5db1-9777-4cd0-98b7-25b0bc44f498%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Support for function application in ORDER BY

2014-06-11 Thread Josh Smeaton
>  Model.objects.filter(...).order_by( F('fld_a').desc(), F('fld_b')).asc() 
) 
>  Model.objects.filter(...).order_by( (F('fld_a')+F('fld_b')).desc() ) 

I actually really like this. It's simple, clear, and gets around the issues 
being discussed. It still requires Expressions to know about ordering (to 
implement the asc/desc methods) but I think that's fine.

The other problem with having ordering objects being of a different type 
means that you would have to call asc or desc. But now I think of it, the 
order_by method could just call asc, by default, on any expressions passed 
in.

Think you've come up with a winner here.

Cheers,

On Wednesday, 11 June 2014 20:58:04 UTC+10, Shai Berger wrote:
>
> On Tuesday 10 June 2014 02:48:14 Josh Smeaton wrote: 
> > > However, I think having some special case code in filter(), annotate() 
> > 
> > and anything else that takes expressions would be OK 
> > 
> > I strongly disagree with this. Expressions are context insensitive at 
> the 
> > moment, which means they can be used anywhere. If we start externalising 
> > behaviour based on the context of use, it'll lead us to some very 
> confusing 
> > code and a tonne of special cases. 
>
> +1 Josh. 
>
> However, per the __neg__ issue, I think you're heading in the wrong 
> direction: 
> ordering shouldn't be a feature of an expression, because an expression 
> with 
> ordering cannot be used the same way: It cannot be combined with other 
> expressions (because the ordering of the result is intuitively ambiguous), 
> it 
> shouldn't be used for comparisons etc. 
>
> So, I think, in terms of implementation (and I'm doing this in horrible 
> style, 
> without looking at your actual patches -- sorry if I'm way off), once you 
> apply 
> ordering to an expression, you should get a different-typed object. 
> Indeed, a 
> wrapper would be suitable, but it should no longer be an expression IMO. 
>
> And in terms of API as well -- the hints should be clear that this is 
> different 
> from normal expression creation. Both "-Expression" and "Desc(Expression)" 
> look like other expressions, so I think they're suboptimal. I'd prefer 
> something like "Expression.desc()" which reads nicely: 
>
> Model.objects.filter(...).order_by( F('fld_a').desc(), 
> F('fld_b')).asc() ) 
> Model.objects.filter(...).order_by( (F('fld_a')+F('fld_b')).desc() 
> ) 
>
> (desc as a property instead of method would read nicer but feels less 
> "right" 
> as Python). 
>
> My 2 cents, 
>
> Shai. 
>

-- 
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/c101f9f8-6b57-48b2-8019-26280be4b9e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Solving the select+1 problem.

2014-06-11 Thread Jacob Kaplan-Moss
I'm not great at Haskell, either, but this looks to me to be very similar
to prefetch_related (
https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
).

Jacob


On Wed, Jun 11, 2014 at 6:15 AM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:

> The "select+1" problem is a problem that people often face in Django.
> Usually, something like select_related solves it, but I don't think that's
> always possible.
>
> Facebook released Haxl today and there's an example of their apprach to
> the problem.
> https://github.com/facebook/Haxl/tree/master/example/sql
>
> I don't know enough Haskel to understand this code, but it could contain
> some very nice ideas that apply to our ORM as well.
>
> Cheers,
> Jonathan
>
> --
> 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/f81a5db1-9777-4cd0-98b7-25b0bc44f498%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/CAK8PqJFJoOXVbOX7C7NmhToVsEizD2ZvWCS1vv_LZpfdRv2ayg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Solving the select+1 problem.

2014-06-11 Thread Alex Gaynor
I also do not really know Haskell (I'm sensing a trend...), that said, it
seems to me the cool part of haxl is that it can be automatic -- analagous
to if writing {{ post.author.name }} in a template caused
select_related("author") to automatically be applied to the queryset that
yielded post.

Alex


On Wed, Jun 11, 2014 at 6:37 AM, Jacob Kaplan-Moss 
wrote:

> I'm not great at Haskell, either, but this looks to me to be very similar
> to prefetch_related (
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
> ).
>
> Jacob
>
>
> On Wed, Jun 11, 2014 at 6:15 AM, Jonathan Slenders <
> jonathan.slend...@gmail.com> wrote:
>
>> The "select+1" problem is a problem that people often face in Django.
>> Usually, something like select_related solves it, but I don't think
>> that's always possible.
>>
>> Facebook released Haxl today and there's an example of their apprach to
>> the problem.
>> https://github.com/facebook/Haxl/tree/master/example/sql
>>
>> I don't know enough Haskel to understand this code, but it could contain
>> some very nice ideas that apply to our ORM as well.
>>
>> Cheers,
>> Jonathan
>>
>> --
>> 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/f81a5db1-9777-4cd0-98b7-25b0bc44f498%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/CAK8PqJFJoOXVbOX7C7NmhToVsEizD2ZvWCS1vv_LZpfdRv2ayg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"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
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
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/CAFRnB2UAGp%2BWPJHm_oq9WLFv5yTvtVT5%3Drs6E46WinL49Q%2B1wA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Loading fixtures once for each TestCase to improve running time

2014-06-11 Thread Josh Smeaton
manfre was nice enough to test this patch out on mssql for me. The subset 
of tests that use fixtures went from 385 seconds to 158 seconds (+2 
failures). The improvement seems to be stable across backends, but isn't 
very significant when considering the entire test suite.

I'm going to abandon this patch and ticket myself - mainly due to the 
sqlite threading issues. If someone else would like to run with it, I'll be 
happy to share any information I have.

- Josh

On Wednesday, 11 June 2014 09:34:14 UTC+10, Josh Smeaton wrote:
>
> I used the patch in the above ticket as a base, and implemented fixture 
> loading in the setUpClass classmethod rather than the setUp method. I found 
> that it improved the total running time of the entire test suite by about 
> 10%, but it improved TestCases that use fixtures by a factor of 3.
>
> https://github.com/jarshwah/django/tree/testcase-optimization
>
> I'm unable to test this patch on Oracle or mssql though, which are known 
> to be a lot slower than most of the other backends (for the test suite). 
> The list of test modules that use fixtures are:
>
> admin_changelist admin_custom_urls admin_docs admin_inlines admin_views 
> admin_widgets aggregation aggregation_regress contenttypes_tests fixtures 
> fixtures_model_package generic_inline_admin known_related_objects 
> m2m_through_regress multiple_database proxy_models raw_query servers 
> syndication_tests test_client test_client_regress test_utils timezones
>
>
> If someone is able to test Oracle or mssql with that set of test modules and 
> report back the difference in time taken between master and the above branch, 
> that'd be extremely useful information.
>
>
> As for profiling the entire test suite:
>
>
> vagrant@djangocore:~$ PYTHONPATH=/django 
> /home/vagrant/.virtualenvs/py2.7/bin/python -m cProfile -s cumulative 
> /django/tests/runtests.py
>
> This shows that for psql, mysql (inno), and sqlite, the majority of 
> (cumulative) time is spent inside the request/response phases of the test 
> client, reversing urls, and rendering templates. I don't think the choice 
> of backend would massively influence these tests (unless transactions 
> themselves are especially slow per backend), so I'm betting that the 
> loaddata/rollback operations are the primary pain points. See my output 
> (with loaddata optimisations) here: 
> https://gist.github.com/jarshwah/42c4cd1f54c8fb3dd273
>
> Unfortunately, this patch has introduced some bad threading issues for 
> sqlite which seg faults for me and also Aymeric in certain conditions. It's 
> definitely not ok to use this code in production. If there isn't 
> significant improvement for oracle or mssql, I'll probably abandon this 
> patch myself.
>
> Cheers
>
> On Saturday, 7 June 2014 18:29:12 UTC+10, Aymeric Augustin wrote:
>>
>> In fact, I just reinvented https://code.djangoproject.com/ticket/20392. 
>>
>> The patch on that ticket is pretty good, I’ll try to review it again. 
>>
>> -- 
>> Aymeric. 
>>
>>
>>
>> On 7 juin 2014, at 10:12, Aymeric Augustin  
>> wrote: 
>>
>> > Hi Josh, 
>> > 
>> > Fixtures don’t receive a lot of attention because they’re hard to 
>> maintain and generally inferior to object generators such as factory_boy. 
>> Still, it would be good to optimize them. 
>> > 
>> > On 7 juin 2014, at 09:34, Josh Smeaton  wrote: 
>> > 
>> >> I've been looking into the django testing infrastructure today to see 
>> if there was any particular reason why the test suite takes so long to run. 
>> > 
>> > You aren’t the first one to notice the overhead of fixtures: 
>> https://code.djangoproject.com/ticket/9449. 
>> > 
>> > That ticket focuses on the cost of parsing fixtures, not loading them. 
>> > 
>> >> Note that the above isn't exactly right, but I think it demonstrates 
>> the problem. Each test_method is given its own TestCase (unnecessary python 
>> overhead) 
>> >> but more importantly, we're not using transactions to get back to the 
>> initial data. We're using transactions to get back to an empty database 
>> before loading fixtures again. 
>> > 
>> > I have a theory for this. Until Django 1.6, Django didn’t have support 
>> for savepoints. All you could do is a full rollback. 
>> > 
>> > So you had a choice between: 
>> > 
>> > - Load fixtures 
>> > - For each test method 
>> > - Start transaction 
>> > - Run test 
>> > - Roll back transaction 
>> > - Truncate tables (that’s awfully slow when you have lots of models, 
>> like Django’s test suite does) 
>> > 
>> > or: 
>> > 
>> > - For each test method 
>> > - Start transaction 
>> > - Load fixtures 
>> > - Run test 
>> > - Roll back transaction 
>> > 
>> > The second solution is /probably/ faster for /some/ use cases, and 
>> certainly for Django’s own test suite. 
>> > 
>> > It may also explain why Django rewraps each method in a test case, but 
>> I’m not sure about that part. 
>> > 
>> > Now, if the test suite is running on a database that s

Re: Solving the select+1 problem.

2014-06-11 Thread Stratos Moros
Given their sample code, my initial impression was that it was indeed 
automatic. Looking a bit closer, there seems to be hardcoded logic 
inside the DataSource (the thing I'm assuming provides getAllUserIds and 
getUsernameById) to specifically fetch all ids and then all names for 
those ids. So they're still doing a manual prefetch_related equivalent 
but at a different abstraction level.


I should note that my Haskell knowledge is also minimal, so it is quite 
possible that I'm misunderstanding something.



On 11 Jun 2014, at 17:36, Alex Gaynor wrote:

I also do not really know Haskell (I'm sensing a trend...), that said, 
it
seems to me the cool part of haxl is that it can be automatic -- 
analagous

to if writing {{ post.author.name }} in a template caused
select_related("author") to automatically be applied to the queryset 
that

yielded post.

Alex


On Wed, Jun 11, 2014 at 6:37 AM, Jacob Kaplan-Moss 


wrote:

I'm not great at Haskell, either, but this looks to me to be very 
similar

to prefetch_related (
https://docs.djangoproject.com/en/dev/ref/models/querysets/#prefetch-related
).

Jacob


On Wed, Jun 11, 2014 at 6:15 AM, Jonathan Slenders <
jonathan.slend...@gmail.com> wrote:

The "select+1" problem is a problem that people often face in 
Django.

Usually, something like select_related solves it, but I don't think
that's always possible.

Facebook released Haxl today and there's an example of their apprach 
to

the problem.
https://github.com/facebook/Haxl/tree/master/example/sql

I don't know enough Haskel to understand this code, but it could 
contain

some very nice ideas that apply to our ORM as well.

Cheers,
Jonathan

--
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/f81a5db1-9777-4cd0-98b7-25b0bc44f498%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/CAK8PqJFJoOXVbOX7C7NmhToVsEizD2ZvWCS1vv_LZpfdRv2ayg%40mail.gmail.com

.

For more options, visit https://groups.google.com/d/optout.





--
"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
GPG Key fingerprint: 125F 5C67 DFE9 4084

--
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/CAFRnB2UAGp%2BWPJHm_oq9WLFv5yTvtVT5%3Drs6E46WinL49Q%2B1wA%40mail.gmail.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/B3FF8C5C-70FA-4781-95A9-2E06CF618AF2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


implementing a ticket submission system

2014-06-11 Thread Anurag Baidyanath
i am implementing a ticket submission system whose model.py file looks loke 
this:
class Ticket(models.Model):
user_id=models.ForeignKey(
User)
category_id=models.ForeignKey(Category)
subject=models.CharField(max_length=100)
message=models.TextField(help_text="enter message")
ticket_id=models.IntegerField(help_text="enter tid",unique=True)
created_date_time=models.DateTimeField(auto_now_add=True)
overdue_date_time=models.DateTimeField(auto_now_add=True)
closed_date_time=models.DateTimeField(auto_now_add=True)
status=models.IntegerField(help_text="enter status",default=0)
reopened_date_time=models.DateTimeField(auto_now_add=True)
topic_priority=models.IntegerField(help_text="enter priority",default=1)
duration_for_reply=models.IntegerField(help_text="enter duration for 
reply",default=24)

i need to take the data submitted by the user(message and subject); and 
generate the ticket_id dynamically for each ticket. Then the data has to be 
saved into the database. please suggest an approach for this.

-- 
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/d20318d4-dce0-4d32-9db7-1dc5d788c48c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: implementing a ticket submission system

2014-06-11 Thread Alexandr Shurigin
I think you need to ask this question in django-users group. This group is for 
core features and bugs discussions.


-- 
Alexandr Shurigin

From: Baidyanath Anurag anurag.fa...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 12 июня 2014 г. at 1:09:54
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  implementing a ticket submission system  

i am implementing a ticket submission system whose model.py file looks loke 
this:
class Ticket(models.Model):
    user_id=models.ForeignKey(
User)
    category_id=models.ForeignKey(Category)
    subject=models.CharField(max_length=100)
    message=models.TextField(help_text="enter message")
    ticket_id=models.IntegerField(help_text="enter tid",unique=True)
    created_date_time=models.DateTimeField(auto_now_add=True)
    overdue_date_time=models.DateTimeField(auto_now_add=True)
    closed_date_time=models.DateTimeField(auto_now_add=True)
    status=models.IntegerField(help_text="enter status",default=0)
    reopened_date_time=models.DateTimeField(auto_now_add=True)
    topic_priority=models.IntegerField(help_text="enter priority",default=1)
    duration_for_reply=models.IntegerField(help_text="enter duration for 
reply",default=24)

i need to take the data submitted by the user(message and subject); and 
generate the ticket_id dynamically for each ticket. Then the data has to be 
saved into the database. please suggest an approach for this.
--
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/d20318d4-dce0-4d32-9db7-1dc5d788c48c%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/etPan.53989c7f.7c3dbd3d.fbcf%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.


Current check for explicit app_label will cause a lot of headaches

2014-06-11 Thread Ben Davis
In stable/1.7.x, I'm getting a lot of these warnings:

venv/src/django/django/contrib/sites/models.py:65: 
RemovedInDjango19Warning: Model class django.contrib.sites.models.Site 
doesn't declare an explicit app_label and either isn't in an application in 
INSTALLED_APPS or else was imported before its application was loaded. This 
will no longer be supported in Django 1.9.
  class Site(models.Model):

This is usually because somewhere in one of my modules I am importing a 
models.py at the top of the module, and that module is needed by something 
else down the import chain. Is there any reason why this check can't be 
done *after* all apps are loaded?  If not, can't we just "lazy load" the 
model, and then run the explicit app_label check after all apps are loaded? 
It's a huge pain to have to constantly track down the import causing the 
warning. It make me never want to import a models.py file anywhere other 
than inside a function (which is bad).

-- 
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/476d7e36-ab40-4d06-8123-35e899e22c6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Current check for explicit app_label will cause a lot of headaches

2014-06-11 Thread Aymeric Augustin
Hi Ben,

This issue is tracked in https://code.djangoproject.com/ticket/21719. You'll 
see in that ticket why I failed to resolve it, and eventually gave up after 
wasting a few day on it.

However, you can avoid it by following two simple good practices (that were 
already true before app-loading):

1) Your models should be defined in an installed application and imported in 
its `/models.py` (or `/models/__init__.py`). This guarantees 
discoverability at startup and attribution to the correct application. Django's 
behavior was ill-defined before the app-loading refactoring.

2) You shouldn't import arbitrary things in your settings nor in the root 
package `/__init__.py` of your installed applications. This guarantees 
that Django can import all your applications first, and then all your models.

Unfortunately, for backwards-compatibility reasons, I couldn't enforce this 
second guideline for the admin and auth contrib apps :-(

Note that it's always a good idea to keep __init__.py empty. That avoid 
accidentally importing unrelated things when you do a deep import. For 
instance, you could believe that `from django.contrib.admin.utils import 
flatten_fieldsets` just imports a function, but in practice it brings the 
entire implementation of the admin in memory, because almost everything is 
imported in `django/contrib/admin/__init__.py`.

To sum up, I agree that the second constraint seems unnecessary, but I've been 
unable to relax it in practice, mostly because of the complexity of 
ModelBase.__new__.

I'm not going to suggest you write a patch ;-) At least I hope this advice 
helps.

-- 
Aymeric.



On 12 juin 2014, at 00:20, Ben Davis  wrote:

> In stable/1.7.x, I'm getting a lot of these warnings:
> 
> venv/src/django/django/contrib/sites/models.py:65: RemovedInDjango19Warning: 
> Model class django.contrib.sites.models.Site doesn't declare an explicit 
> app_label and either isn't in an application in INSTALLED_APPS or else was 
> imported before its application was loaded. This will no longer be supported 
> in Django 1.9.
>   class Site(models.Model):
> 
> This is usually because somewhere in one of my modules I am importing a 
> models.py at the top of the module, and that module is needed by something 
> else down the import chain. Is there any reason why this check can't be done 
> *after* all apps are loaded?  If not, can't we just "lazy load" the model, 
> and then run the explicit app_label check after all apps are loaded? It's a 
> huge pain to have to constantly track down the import causing the warning. It 
> make me never want to import a models.py file anywhere other than inside a 
> function (which is bad).
> 
> -- 
> 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/476d7e36-ab40-4d06-8123-35e899e22c6f%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/F9079450-5233-4851-ADF7-9D3B1A22BD26%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.