Test problems after upgrading to 1.8

[o_r]

I've recently upgraded from 1.3 to 1.8. I have a rather large testsuite, 
and by the end of the upgrade all the tests passed. Now I've added some new 
models, and made the new migration, and it seemed to work as expected, but 
when I try to run my tests again now, I get an error message like this:

*CommandError: Database test_27_10 couldn't be flushed. Possible reasons:*

*  * The database isn't running or isn't configured correctly.*

*  * At least one of the expected database tables doesn't exist.*

*  * The SQL was invalid.*

*Hint: Look at the output of 'django-admin sqlflush'. That's the SQL this 
command wasn't able to run.*

*The full error: cannot truncate a table referenced in a foreign key 
constraint*

*DETAIL:  Table "auth_message" references "auth_user".*

*HINT:  Truncate table "auth_message" at the same time, or use TRUNCATE ... 
CASCADE.*


I used to run south, so as part of the upgrade, I used the --fake option on 
everything, but later on I removed the migration for contenttypes and auth, 
and ran the migration again.

Any Ideas of what is wrong and how to fix it? Thanks!

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

Re: Test problems after upgrading to 1.8

[Tim Graham]

It seems a bit difficult to debug from what you provided so far. One idea: 
do you have migrations for all your apps?

If you could put together a minimal project that reproduces the problem 
that would be useful.

On Wednesday, October 28, 2015 at 4:19:25 AM UTC-4, o_r wrote:
>
> I've recently upgraded from 1.3 to 1.8. I have a rather large testsuite, 
> and by the end of the upgrade all the tests passed. Now I've added some new 
> models, and made the new migration, and it seemed to work as expected, but 
> when I try to run my tests again now, I get an error message like this:
>
> *CommandError: Database test_27_10 couldn't be flushed. Possible reasons:*
>
> *  * The database isn't running or isn't configured correctly.*
>
> *  * At least one of the expected database tables doesn't exist.*
>
> *  * The SQL was invalid.*
>
> *Hint: Look at the output of 'django-admin sqlflush'. That's the SQL this 
> command wasn't able to run.*
>
> *The full error: cannot truncate a table referenced in a foreign key 
> constraint*
>
> *DETAIL:  Table "auth_message" references "auth_user".*
>
> *HINT:  Truncate table "auth_message" at the same time, or use TRUNCATE 
> ... CASCADE.*
>
>
> I used to run south, so as part of the upgrade, I used the --fake option 
> on everything, but later on I removed the migration for contenttypes and 
> auth, and ran the migration again.
>
> Any Ideas of what is wrong and how to fix it? Thanks!
>

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

Re: [django_tables2] Expected table or queryset, not 'str'.

[Leutrim Osmani]

Can you please tell me how did you fixed this error ?

On Monday, April 29, 2013 at 9:21:29 AM UTC+2, binith a k wrote:
>
> You were correct, it was indeed a version problem.
> I was using latest django-tables2 in my new python virtual env and I had 
> an older version (of django-tables2) installed as default, and the 
> PYTHONPATH environment variable was pointing to the older version.
>
> Problem solved, thanks for the time
>
> thanks
> -binith
>
> On Friday, 26 April 2013 07:25:35 UTC-7, Binith Babu wrote:
>>
>> I am sorry I coud not find a solution in this thread
>>
>> Did you mean I am using an older version of django tables2 ?
>> In that case I am not, I am using the latest version installed with pip.
>> May be its my mistake, I am still trying to figure whether I am doing 
>> something wrong.
>> WIll post back if I find something.
>>
>> Thanks
>> binith
>>
>>
>>
>> On Friday, 26 April 2013 06:53:06 UTC-7, Tom Evans wrote:
>>>
>>> On Fri, Apr 26, 2013 at 2:30 PM, Binith Babu  wrote: 
>>> > 
>>> > I got the same error today, anybody know a solution? 
>>> > 
>>>
>>> Apart from the solution I already posted to the list in this thread? 
>>>
>>> Cheers 
>>>
>>> Tom 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e8aa4e21-9ba9-4020-84fd-800b50a47151%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Test problems after upgrading to 1.8

[o_r]

I removed the table auth_message from my database, I tried to run it once 
more, and then I got a new similar message, so I removed that table too, 
and now it works again. I still don't understand why I suddenly got this 
error, but it's working again, so I'm happy :)

onsdag 28. oktober 2015 09.19.25 UTC+1 skrev o_r følgende:
>
> I've recently upgraded from 1.3 to 1.8. I have a rather large testsuite, 
> and by the end of the upgrade all the tests passed. Now I've added some new 
> models, and made the new migration, and it seemed to work as expected, but 
> when I try to run my tests again now, I get an error message like this:
>
> *CommandError: Database test_27_10 couldn't be flushed. Possible reasons:*
>
> *  * The database isn't running or isn't configured correctly.*
>
> *  * At least one of the expected database tables doesn't exist.*
>
> *  * The SQL was invalid.*
>
> *Hint: Look at the output of 'django-admin sqlflush'. That's the SQL this 
> command wasn't able to run.*
>
> *The full error: cannot truncate a table referenced in a foreign key 
> constraint*
>
> *DETAIL:  Table "auth_message" references "auth_user".*
>
> *HINT:  Truncate table "auth_message" at the same time, or use TRUNCATE 
> ... CASCADE.*
>
>
> I used to run south, so as part of the upgrade, I used the --fake option 
> on everything, but later on I removed the migration for contenttypes and 
> auth, and ran the migration again.
>
> Any Ideas of what is wrong and how to fix it? Thanks!
>

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

Re: IntComma without RequestContext

[Michael Newman]

Thank you. Knew I was missing something easy.



On Tuesday, October 27, 2015 at 8:54:08 PM UTC-4, foobar wrote:
>
> Your language string is backwards: 
>
> >>> activate("en-us") 
> >>> intcomma(1000) 
> '1,000' 
>
> >>> activate("en") 
> >>> intcomma(1000) 
> '1,000' 
>
>
> use_l10n=False in a template is: 
>
> {% load l10n %} 
>
> {% localize off %} 
> {{ value }} 
> {% endlocalize %} 
>
> https://docs.djangoproject.com/en/1.8/topics/i18n/formatting/#localize 
>
> 2015-10-28 1:37 GMT+02:00 Michael Newman >: 
>
> > I am feeling a little lost, a project that I have used intcomma in 
> reliably 
> > on an update suddenly stopped getting the commas inserted. This is for 
> an 
> > out of request cycle email. 
> > 
> > Attempting activate the language doesn't seem to change anything. Am I 
> > missing something simple here? 
> > 
>  from django.contrib.humanize.templatetags.humanize import intcomma 
>  intcomma(1000) 
> > u'1000' 
>  intcomma("1000", use_l10n=False) #not sure how to do this in 
> templates 
> > u'1,000' 
>  from django.utils.translation import activate, get_language 
>  get_language() 
> > u'us-en' 
>  activate("us-en") 
>  intcomma("1000") 
> > u'1000' 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to django-users...@googlegroups.com . 
> > To post to this group, send email to django...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/django-users. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-users/30892a71-1a41-488e-b9f9-3d71cfc6abcb%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/23d9828c-f1ab-425a-9fe3-49e0703a542c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Missing default callable breaks migration

[Richard Buck]

If I try to change the default on a model field from one callable to 
another, the migration will fail if the old callable is no longer 
available. It appears this is because the migration system tries to call 
the old callable to determine if it returns a different value from the new. 

I don't think this should cause an error; it's not unusual to delete/rename 
a function used as a field default. 

Moreover, I think comparing output from the old default is a bad idea; I 
initially had migration failure because I had changed the default from a 
function that returned timezone-aware dates to one that returned 
timezone-naive dates. 

Hence I think this general behaviour is a bug that needs to be fixed; 
exceptions trying to compare old and new defaults during migration should 
be handled and not break the migration.

Note that I was able to work around this by modifying the previous default 
in the earlier migration file.

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

include template which extends something else

[svewa]

Hi all,

sorry if it might be a stupid question for pro's but it seems I still miss 
a deeper knowledge of some design aspects. What I try to do is the 
following:


{% for obj in objects %}

{% include 'item.html' with object=obj %}

{% endfor %}



this I need to to in three different apps with slightly varying appearance 
of item.html.

So my idea was to create a root_item.html in my root template folder and 
simply do in item.html the following::

{% extends "root_item.html" %}
{% block anyblock %}
{% endblock %}


I'am so far that I guess I know that this will not work. Could anyone 
explain to me the prefered way to achieve this? In words, I need a base 
template which extensions should be rendered as list items...

Sorry I'am shure it is easy but I am stuck  

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

Re: include template which extends something else

[Tim Graham]

I think that's a limitation described in the {% include %} docs: 
https://docs.djangoproject.com/en/1.8/ref/templates/builtins/#include. See 
the "Note" box where it says:

The include 

 
tag should be considered as an implementation of “render this subtemplate 
and include the HTML”, not as “parse this subtemplate and include its 
contents as if it were part of the parent”. This means that there is no 
shared state between included templates – each include is a completely 
independent rendering process.

Blocks are evaluated *before* they are included. This means that a template 
that includes blocks from another will contain blocks that have *already 
been evaluated and rendered* - not blocks that can be overridden by, for 
example, an extending template.

It's difficult for me to make a suggestion about how to structure things 
without a more complete understanding of what you're trying to do.

On Wednesday, October 28, 2015 at 11:28:07 AM UTC-4, svewa wrote:
>
> Hi all,
>
> sorry if it might be a stupid question for pro's but it seems I still miss 
> a deeper knowledge of some design aspects. What I try to do is the 
> following:
>
> 
> {% for obj in objects %}
> 
> {% include 'item.html' with object=obj %}
> 
> {% endfor %}
> 
>
>
> this I need to to in three different apps with slightly varying appearance 
> of item.html.
>
> So my idea was to create a root_item.html in my root template folder and 
> simply do in item.html the following::
>
> {% extends "root_item.html" %}
> {% block anyblock %}
> {% endblock %}
>
>
> I'am so far that I guess I know that this will not work. Could anyone 
> explain to me the prefered way to achieve this? In words, I need a base 
> template which extensions should be rendered as list items...
>
> Sorry I'am shure it is easy but I am stuck  
>

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

Re: Missing default callable breaks migration

[Tim Graham]

Please read 
https://docs.djangoproject.com/en/stable/topics/migrations/#historical-models

In particular, "References to functions in field options such as upload_to 
and limit_choices_to and model manager declarations with managers having 
use_in_migrations = True are serialized in migrations, so the functions and 
classes will need to be kept around for as long as there is a migration 
referencing them."

The crash about timezone/non-timezone comparison is tracked in 
https://code.djangoproject.com/ticket/24822. Feel free to try to implement 
a patch if you are interested and able!

On Wednesday, October 28, 2015 at 11:16:10 AM UTC-4, Richard Buck wrote:
>
> If I try to change the default on a model field from one callable to 
> another, the migration will fail if the old callable is no longer 
> available. It appears this is because the migration system tries to call 
> the old callable to determine if it returns a different value from the new. 
>
> I don't think this should cause an error; it's not unusual to 
> delete/rename a function used as a field default. 
>
> Moreover, I think comparing output from the old default is a bad idea; I 
> initially had migration failure because I had changed the default from a 
> function that returned timezone-aware dates to one that returned 
> timezone-naive dates. 
>
> Hence I think this general behaviour is a bug that needs to be fixed; 
> exceptions trying to compare old and new defaults during migration should 
> be handled and not break the migration.
>
> Note that I was able to work around this by modifying the previous default 
> in the earlier migration file.
>

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

Re: How to create a global management command?

[Scot Hacker]

Right - even though a management command must live inside of an app, all of 
them work "globally" across the project.  I often include an app called 
"base" in my projects for just this purpose - it includes management 
commands and utility functions that don't  belong logically to any other 
app.

./s

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1b9194ba-34b7-4d03-8f3f-f08a5507729f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: include template which extends something else

[Sven Wanner]

Thanks for your quick reply. Yes, this is also what I found, so I was quite
shure that my code will never work. What I try to do is to render a list of
database objects. But not only on one page but on different pages and with
slightly different designs in each of the lists. So my plan was, to avoid
writing individual templates for each list, to create one base template for
the general appearance of such list items and only adapt blocks on each
individual list.

Explained the other way around, how would I render a template.html which
needs a database object  in a for loop and which extends a base_template
html?

Hope I achieved to explain the problem well enough...

2015-10-28 16:39 GMT+01:00 Tim Graham :

> I think that's a limitation described in the {% include %} docs:
> https://docs.djangoproject.com/en/1.8/ref/templates/builtins/#include.
> See the "Note" box where it says:
>
> The include
> 
> tag should be considered as an implementation of “render this subtemplate
> and include the HTML”, not as “parse this subtemplate and include its
> contents as if it were part of the parent”. This means that there is no
> shared state between included templates – each include is a completely
> independent rendering process.
>
> Blocks are evaluated *before* they are included. This means that a
> template that includes blocks from another will contain blocks that have 
> *already
> been evaluated and rendered* - not blocks that can be overridden by, for
> example, an extending template.
> 
> It's difficult for me to make a suggestion about how to structure things
> without a more complete understanding of what you're trying to do.
>
> On Wednesday, October 28, 2015 at 11:28:07 AM UTC-4, svewa wrote:
>>
>> Hi all,
>>
>> sorry if it might be a stupid question for pro's but it seems I still
>> miss a deeper knowledge of some design aspects. What I try to do is the
>> following:
>>
>> 
>> {% for obj in objects %}
>> 
>> {% include 'item.html' with object=obj %}
>> 
>> {% endfor %}
>> 
>>
>>
>> this I need to to in three different apps with slightly varying
>> appearance of item.html.
>>
>> So my idea was to create a root_item.html in my root template folder and
>> simply do in item.html the following::
>>
>> {% extends "root_item.html" %}
>> {% block anyblock %}
>> {% endblock %}
>>
>>
>> I'am so far that I guess I know that this will not work. Could anyone
>> explain to me the prefered way to achieve this? In words, I need a base
>> template which extensions should be rendered as list items...
>>
>> Sorry I'am shure it is easy but I am stuck
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/SFh41AI0dcM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/af32f8fd-e83b-4767-8f37-eaccc1ec70b8%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAH4Xs%2BO%2Bk20ht4Lhiw9eA6jNcs-yC8qEj9MzGCUpvKbjEFFnOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: include template which extends something else

[Tim Graham]

I don't think you can structure your templates that way. Maybe using {% if 
%} tags in your included template would be enough (instead of using {% 
extends %}).

On Wednesday, October 28, 2015 at 11:51:12 AM UTC-4, svewa wrote:
>
> Thanks for your quick reply. Yes, this is also what I found, so I was 
> quite shure that my code will never work. What I try to do is to render a 
> list of database objects. But not only on one page but on different pages 
> and with slightly different designs in each of the lists. So my plan was, 
> to avoid writing individual templates for each list, to create one base 
> template for the general appearance of such list items and only adapt 
> blocks on each individual list.
>
> Explained the other way around, how would I render a template.html which 
> needs a database object  in a for loop and which extends a base_template 
> html?
>
> Hope I achieved to explain the problem well enough...
>
> 2015-10-28 16:39 GMT+01:00 Tim Graham >:
>
>> I think that's a limitation described in the {% include %} docs: 
>> https://docs.djangoproject.com/en/1.8/ref/templates/builtins/#include. 
>> See the "Note" box where it says:
>>
>> The include 
>> 
>>  
>> tag should be considered as an implementation of “render this subtemplate 
>> and include the HTML”, not as “parse this subtemplate and include its 
>> contents as if it were part of the parent”. This means that there is no 
>> shared state between included templates – each include is a completely 
>> independent rendering process.
>>
>> Blocks are evaluated *before* they are included. This means that a 
>> template that includes blocks from another will contain blocks that have 
>> *already 
>> been evaluated and rendered* - not blocks that can be overridden by, for 
>> example, an extending template.
>> 
>> It's difficult for me to make a suggestion about how to structure things 
>> without a more complete understanding of what you're trying to do.
>>
>> On Wednesday, October 28, 2015 at 11:28:07 AM UTC-4, svewa wrote:
>>>
>>> Hi all,
>>>
>>> sorry if it might be a stupid question for pro's but it seems I still 
>>> miss a deeper knowledge of some design aspects. What I try to do is the 
>>> following:
>>>
>>> 
>>> {% for obj in objects %}
>>> 
>>> {% include 'item.html' with object=obj %}
>>> 
>>> {% endfor %}
>>> 
>>>
>>>
>>> this I need to to in three different apps with slightly varying 
>>> appearance of item.html.
>>>
>>> So my idea was to create a root_item.html in my root template folder and 
>>> simply do in item.html the following::
>>>
>>> {% extends "root_item.html" %}
>>> {% block anyblock %}
>>> {% endblock %}
>>>
>>>
>>> I'am so far that I guess I know that this will not work. Could anyone 
>>> explain to me the prefered way to achieve this? In words, I need a base 
>>> template which extensions should be rendered as list items...
>>>
>>> Sorry I'am shure it is easy but I am stuck  
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-users/SFh41AI0dcM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/af32f8fd-e83b-4767-8f37-eaccc1ec70b8%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/858bfa32-3ace-475d-8c74-f4c8722fc0c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: include template which extends something else

[Carl Meyer]

Hi Sven,

On 10/28/2015 09:50 AM, Sven Wanner wrote:
> Thanks for your quick reply. Yes, this is also what I found, so I was
> quite shure that my code will never work. What I try to do is to render
> a list of database objects. But not only on one page but on different
> pages and with slightly different designs in each of the lists. So my
> plan was, to avoid writing individual templates for each list, to create
> one base template for the general appearance of such list items and only
> adapt blocks on each individual list.
> 
> Explained the other way around, how would I render a template.html which
> needs a database object  in a for loop and which extends a base_template
> html?
> 
> Hope I achieved to explain the problem well enough...

If I'm understanding right, I think blocks do work fine for your situation.

What you can't do, as Tim explained, is have blocks in an included
template interact with blocks in the including template. They are two
totally separate renders, with totally separate inheritance hierarchies.
But there's no problem with included templates having their own
independent inheritance hierarchy, with blocks.

So you can have an `item_base.html` that contains `{% block someblock
%}{% endblock %}`, and then define `item_foo.html` that `{% extends
"item_base.html" %}` and has `{% block someblock %}foo content{%
endblock %}`, and you can have a `main.html` that has `{% include
"item_foo.html" %}`, and all that should work fine -- the included
portion should display "foo content".

What you can't do is expect the `{% block someblock %}` in
`item_base.html` or `item_foo.html` to interact in any way with a `{%
block someblock %}` in `main.html` (or its parent). The included
template and the including template have separate and unrelated
inheritance and blocks.

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: include template which extends something else

[Sven Wanner]

Ok, it's a pitty, but you're totally right. Using if in my template should
be also fine. Not of that elegance I planned  ;) , but will definitely
work, too.

Thank you

2015-10-28 17:04 GMT+01:00 Carl Meyer :

> Hi Sven,
>
> On 10/28/2015 09:50 AM, Sven Wanner wrote:
> > Thanks for your quick reply. Yes, this is also what I found, so I was
> > quite shure that my code will never work. What I try to do is to render
> > a list of database objects. But not only on one page but on different
> > pages and with slightly different designs in each of the lists. So my
> > plan was, to avoid writing individual templates for each list, to create
> > one base template for the general appearance of such list items and only
> > adapt blocks on each individual list.
> >
> > Explained the other way around, how would I render a template.html which
> > needs a database object  in a for loop and which extends a base_template
> > html?
> >
> > Hope I achieved to explain the problem well enough...
>
> If I'm understanding right, I think blocks do work fine for your situation.
>
> What you can't do, as Tim explained, is have blocks in an included
> template interact with blocks in the including template. They are two
> totally separate renders, with totally separate inheritance hierarchies.
> But there's no problem with included templates having their own
> independent inheritance hierarchy, with blocks.
>
> So you can have an `item_base.html` that contains `{% block someblock
> %}{% endblock %}`, and then define `item_foo.html` that `{% extends
> "item_base.html" %}` and has `{% block someblock %}foo content{%
> endblock %}`, and you can have a `main.html` that has `{% include
> "item_foo.html" %}`, and all that should work fine -- the included
> portion should display "foo content".
>
> What you can't do is expect the `{% block someblock %}` in
> `item_base.html` or `item_foo.html` to interact in any way with a `{%
> block someblock %}` in `main.html` (or its parent). The included
> template and the including template have separate and unrelated
> inheritance and blocks.
>
> Carl
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/SFh41AI0dcM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/5630F1F6.5090100%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Missing default callable breaks migration

[Simon Charette]

I would add that since migration files are normal Python modules you can 
simply replace the previously imported callable in the referencing 
migrations by inlining it.

Simon

Le mercredi 28 octobre 2015 11:33:28 UTC-4, Tim Graham a écrit :
>
> Please read 
> https://docs.djangoproject.com/en/stable/topics/migrations/#historical-models
>
> In particular, "References to functions in field options such as upload_to 
> and limit_choices_to and model manager declarations with managers having 
> use_in_migrations = True are serialized in migrations, so the functions 
> and classes will need to be kept around for as long as there is a migration 
> referencing them."
>
> The crash about timezone/non-timezone comparison is tracked in 
> https://code.djangoproject.com/ticket/24822. Feel free to try to 
> implement a patch if you are interested and able!
>
> On Wednesday, October 28, 2015 at 11:16:10 AM UTC-4, Richard Buck wrote:
>>
>> If I try to change the default on a model field from one callable to 
>> another, the migration will fail if the old callable is no longer 
>> available. It appears this is because the migration system tries to call 
>> the old callable to determine if it returns a different value from the new. 
>>
>> I don't think this should cause an error; it's not unusual to 
>> delete/rename a function used as a field default. 
>>
>> Moreover, I think comparing output from the old default is a bad idea; I 
>> initially had migration failure because I had changed the default from a 
>> function that returned timezone-aware dates to one that returned 
>> timezone-naive dates. 
>>
>> Hence I think this general behaviour is a bug that needs to be fixed; 
>> exceptions trying to compare old and new defaults during migration should 
>> be handled and not break the migration.
>>
>> Note that I was able to work around this by modifying the previous 
>> default in the earlier migration file.
>>
>

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

Re: include template which extends something else

[Carl Meyer]

On 10/28/2015 10:11 AM, Sven Wanner wrote:
> Ok, it's a pitty, but you're totally right. Using if in my template
> should be also fine. Not of that elegance I planned  ;) , but will
> definitely work, too.

I'm not sure what you mean. I thought I just explained how you can use
`extends` in an included template -- I think that should work just fine
for your use case (and I just tested to verify that it does work).

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: include template which extends something else

[Sven Wanner]

Yes, sorry I was confused... No I don't get what you mean. I think thats
exactly what I tried to do.

I have kind of a main.html doing that:

{% block my-wall %}


{% for obj in objects %}

{% include 'wall_item.html' with object=obj %}

{% endfor %}


{% endblock %}

wall_item.html looks like that:

{% extends "wallitem.html" %}

{% block wall_item_header %}
something
{% endblock %}

and wallitem.html like that:



{% block wall_item_header %}
{% endblock %}




2015-10-28 17:13 GMT+01:00 Carl Meyer :

> On 10/28/2015 10:11 AM, Sven Wanner wrote:
> > Ok, it's a pitty, but you're totally right. Using if in my template
> > should be also fine. Not of that elegance I planned  ;) , but will
> > definitely work, too.
>
> I'm not sure what you mean. I thought I just explained how you can use
> `extends` in an included template -- I think that should work just fine
> for your use case (and I just tested to verify that it does work).
>
> Carl
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/SFh41AI0dcM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/5630F421.2020906%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: include template which extends something else

[Carl Meyer]

On 10/28/2015 10:25 AM, Sven Wanner wrote:
> Yes, sorry I was confused... No I don't get what you mean. I think thats
> exactly what I tried to do. 
> 
> I have kind of a main.html doing that:
> 
> {% block my-wall %}
> 
> 
> {% for obj in objects %}
> 
> {% include 'wall_item.html' with object=obj %}
> 
> {% endfor %}
> 
> 
> {% endblock %}
> 
> wall_item.html looks like that:
> 
> {% extends "wallitem.html" %}
> 
> {% block wall_item_header %}
> something
> {% endblock %}
> 
> and wallitem.html like that:
> 
> 
> 
> {% block wall_item_header %}
> {% endblock %}
> 
> 

That template structure should work just fine. I just tested here with a
similar set of templates and it worked. So there's something else going
on. Can you be more specific about how it fails? Do you get an error?
Unexpected output in some way?

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: include template which extends something else

[Sven Wanner]

Oh man sorry, there was something wrong with finding the template but many
thanks for your advices. It helped me a lot even if the problem was
blindness. But anyway, I am happy now.

Best regards to you

2015-10-28 17:25 GMT+01:00 Sven Wanner :

> Yes, sorry I was confused... No I don't get what you mean. I think thats
> exactly what I tried to do.
>
> I have kind of a main.html doing that:
>
> {% block my-wall %}
> 
> 
> {% for obj in objects %}
> 
> {% include 'wall_item.html' with object=obj %}
> 
> {% endfor %}
> 
> 
> {% endblock %}
>
> wall_item.html looks like that:
>
> {% extends "wallitem.html" %}
>
> {% block wall_item_header %}
> something
> {% endblock %}
>
> and wallitem.html like that:
>
> 
> 
> {% block wall_item_header %}
> {% endblock %}
> 
> 
>
>
> 2015-10-28 17:13 GMT+01:00 Carl Meyer :
>
>> On 10/28/2015 10:11 AM, Sven Wanner wrote:
>> > Ok, it's a pitty, but you're totally right. Using if in my template
>> > should be also fine. Not of that elegance I planned  ;) , but will
>> > definitely work, too.
>>
>> I'm not sure what you mean. I thought I just explained how you can use
>> `extends` in an included template -- I think that should work just fine
>> for your use case (and I just tested to verify that it does work).
>>
>> Carl
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-users/SFh41AI0dcM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/5630F421.2020906%40oddbird.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Running migrations on the non-default database fails

[Gergely Polonkai]

Hello,

I have an application which, due to low usage, used SQLite in production.
Now the demand has risen for the app, and SQLite can't really keep up with
with all the new users. We decided to move to PostgreSQL.

The DB is now up and running, but to cause as short downtime as possible, I
added a new database to settings.py, and tried to run migrations on it:

python manage.py migrate --database postgre

The first few ran fine, but one of them tried to do a RunPython function
which should have modified the value of a column that had been removed from
the production database in a later migration. At this point migrations
failed: it turned out that, despite the --database parameter, RunPython
wanted to iterate through the rows of the production database.

Is this a problem/limitation in Django, or should I update my migration
functions to use the correct database? If the latter, how do I know which
database to use?

Best,
Gergely

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

Wherenode?

[varun naganathan]

Can anybody please explain what a django WhereNode is? Also provide any 
possible references/docs if available including its implementation in the 
source code! Thanks.

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

Re: Wherenode?

[Tim Graham]

GitHub has a nice feature that allows you to search a repository:

https://github.com/django/django/search?utf8=%E2%9C%93&q=WhereNode

On Wednesday, October 28, 2015 at 1:32:40 PM UTC-4, varun naganathan wrote:
>
> Can anybody please explain what a django WhereNode is? Also provide any 
> possible references/docs if available including its implementation in the 
> source code! Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/62f9d4b0-137b-4d80-b221-0d993ec79590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running migrations on the non-default database fails

[Tim Graham]

I think this bit from the Django 1.8 release notes might help:

* The migration operations RunPython 

 
and RunSQL 

 
now call the allow_migrate() 
 
method of database routers. The router can use the newly introduced 
app_label and hints arguments to make a routing decision. To take advantage 
of this feature you need to update the router to the new allow_migrate 
signature, see the *deprecation section* 

 
for more details.

On Wednesday, October 28, 2015 at 12:51:44 PM UTC-4, Gergely Polonkai wrote:
>
> Hello,
>
> I have an application which, due to low usage, used SQLite in production. 
> Now the demand has risen for the app, and SQLite can't really keep up with 
> with all the new users. We decided to move to PostgreSQL.
>
> The DB is now up and running, but to cause as short downtime as possible, 
> I added a new database to settings.py, and tried to run migrations on it:
>
> python manage.py migrate --database postgre
>
> The first few ran fine, but one of them tried to do a RunPython function 
> which should have modified the value of a column that had been removed from 
> the production database in a later migration. At this point migrations 
> failed: it turned out that, despite the --database parameter, RunPython 
> wanted to iterate through the rows of the production database.
>
> Is this a problem/limitation in Django, or should I update my migration 
> functions to use the correct database? If the latter, how do I know which 
> database to use?
>
> Best,
> Gergely
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6e15d12c-f8ce-4daa-a795-69c169db43ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Polymorphic class and geomodels?

[Collin Anderson]

Hello,

Are you trying to combine multiple models into one, like this?

class PolyModel(pdmpunto, pdmtransetto, pdmarea):
pass

You could also try asking on the geodjango list: 
http://groups.google.com/group/geodjango

Collin

On Monday, October 26, 2015 at 7:18:24 AM UTC-4, Luca Moiana wrote:
>
> Hi, working on my first django app, and run into a problem.
>
> I tend to create geodjango objects, and add all data from external tables 
> with pk.
>
> Then I want to have different geometries 8points, lines, polygons) into a 
> unique polymorphic class, can I do that?
>
> I have an error that I'll document later, and I'm trying to figure out 
> what to do.
>
> Here is the model:
> import datetime
>
> from django.db import models
> from django.contrib.gis.db import models as geomodels
> from django.utils import timezone
> from django.forms import ModelForm
> from polymorphic import PolymorphicModel
>
> # Geometria linea da monitorare
> class geolinea(geomodels.Model):
> progetto = models.CharField(max_length=14, primary_key=True)
> geom = geomodels.MultiLineStringField()
> objects = geomodels.GeoManager()
> def __str__(self):
> return '%s' % (self.progetto)
> # Oggetto Progetto soggetto a PMA
> class linea(models.Model):
> progetto = models.ForeignKey(geolinea)
> nome = models.CharField(max_length=200)
> TENSIONE = (
> ('132', '132kV'),
> ('150', '150kV'),
> ('220', '220kV'),
> ('380', '380kV'),
> )
> tensione = models.CharField(max_length=5,
> choices=TENSIONE)
> def __str__(self):
> return '%s' % (self.nome)
>
> # Geometria dei pdm
> class pdmpunto(geomodels.Model):
> linea = models.ForeignKey(linea)
> numero = models.CharField(max_length=3)
> geom = geomodels.PointField()
> objects = geomodels.GeoManager()
>
> class pdmtransetto(geomodels.Model):
> linea = models.ForeignKey(linea)
> numero = models.CharField(max_length=3)
> geom = geomodels.LineStringField()
> objects = geomodels.GeoManager()
>
> class pdmarea(geomodels.Model):
> linea = models.ForeignKey(linea)
> numero = models.CharField(max_length=3)
> geom = geomodels.PolygonField()
> objects = geomodels.GeoManager()
>
> class pdm(PolymorphicModel):
> numero = models.CharField(max_length=14, primary_key=True)
> class punto(pdm):
> rifpunto = models.ForeignKey(pdmpunto)
> class transetto(pdm):
> riftransetto = models.ForeignKey(pdmtransetto)
> class area(pdm):
> rifarea = models.ForeignKey(pdmarea)
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/45f813d4-c476-4cc5-a299-03fb10edd6b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flakey tests and django.db.utils.InterfaceError: connection already closed

[Collin Anderson]

Hello,

Here are some questions that might help debugging this:

Do other tests that use the database run ok?

If you run _only_ this test, is it still a problem?

Are you using threads at all?

Is there an exception that's being silenced somewhere else?

Collin


On Tuesday, October 27, 2015 at 9:14:13 AM UTC-4, Christopher R. wrote:
>
> Have you been able to fix the problem? I am encountering the same issue on 
> both Django 1.8.4 and 1.8.5.
>
> Any help would be appreciated.
>
> On Thursday, October 8, 2015 at 3:38:16 PM UTC+1, thinkwell wrote:
>>
>> I could use some assistance in troubleshooting a psycopg2.InterfaceError 
>> problem that has erratic behavior. Here is the test module 
>>  suite that I'm running to test these 
>> models , and in this state all the tests 
>> in the module pass. However, it's extremely easy to trigger a 
>> psycopg2.InterfaceError, although not relating to the lines changed. For 
>> example, if I change:
>>
>> class TestSilly(SimpleTestCase): 
>>   
>> def test_is_not_false(self): 
>> self.assertTrue(False is not True)
>>
>>
>> to 
>>
>> class TestSilly(TestCase): 
>>   
>> def test_is_not_false(self): 
>> self.assertTrue(False is not True)
>>
>>   
>>
>> Then this error is raised, but referencing TestPolicyModel instead of 
>> TestSilly!
>>
>> ==
>> ERROR: test_toggle_autofix (accounts.tests.test_models.TestPolicyModel)
>> --
>> Traceback (most recent call last):
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
>> line 137, in _cursor
>> return self.create_cursor()
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
>> , line 212, in create_cursor
>> cursor = self.connection.cursor()
>> psycopg2.InterfaceError: connection already closed
>>
>> The above exception was the direct cause of the following exception:
>>
>> Traceback (most recent call last):
>>   File "apps/accounts/tests/test_models.py", line 174, in 
>> test_toggle_autofix
>> p = Policy.objects.first()
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/models/manager.py", 
>> line 127, in manager_method
>> return getattr(self.get_queryset(), name)(*args, **kwargs)
>>   File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py"
>> , line 490, in first
>> objects = list((self if self.ordered else self.order_by('pk'))[:1])
>>   File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py"
>> , line 162, in __iter__
>> self._fetch_all()
>>   File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py"
>> , line 965, in _fetch_all
>> self._result_cache = list(self.iterator())
>>   File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py"
>> , line 238, in iterator
>> results = compiler.execute_sql()
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/models/sql/compiler.py"
>> , line 838, in execute_sql
>> cursor = self.connection.cursor()
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
>> line 164, in cursor
>> cursor = self.make_cursor(self._cursor())
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
>> line 137, in _cursor
>> return self.create_cursor()
>>   File "/usr/local/lib/python3.4/dist-packages/django/db/utils.py", line 
>> 97, in __exit__
>> six.reraise(dj_exc_type, dj_exc_value, traceback)
>>   File "/usr/local/lib/python3.4/dist-packages/django/utils/six.py", 
>> line 658, in reraise
>> raise value.with_traceback(tb)
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
>> line 137, in _cursor
>> return self.create_cursor()
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
>> , line 212, in create_cursor
>> cursor = self.connection.cursor()
>> django.db.utils.InterfaceError: connection already closed
>>
>>
>> For another example, if I change 
>>
>> TestPolicyModel(TestCase)
>>
>>
>> to
>>
>> TestPolicyModel(SimpleTestCase)
>>
>>
>> then, I get the following error regarding TestRedwoodModel
>>
>> ==
>> ERROR: setUpClass (accounts.tests.test_models.TestRedwoodModel)
>> --
>> Traceback (most recent call last):
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/base.py", 
>> line 137, in _cursor
>> return self.create_cursor()
>>   File 
>> "/usr/local/lib/python3.4/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
>> , line 212, in create_cursor
>> cursor = self.connection.cursor()
>> psycopg2.InterfaceError: connection already 

Re: Django Models Joining and Normalising

[Collin Anderson]

Hello,

I'd personally keep it all in one model for as long as possible. It will 
really simplify queries and it should make your code a lot cleaner. Wait 
til you have some actual performance problems before splitting the models 
up.

Collin

On Wednesday, October 14, 2015 at 12:11:55 PM UTC-4, Yunti wrote:
>
> I'm still relatively new to Django and now working on a project that has 
> much more complex models than I've used before.  
>
> The question is about when is it best to separate out large models into 
> separate models (and the impact caused by joining the smaller models 
> together and also keeping data normalised).  
>
> I'm trying to model magazine subscriptions, which are available from 
> different suppliers - the costs vary slightly per region (due to delivery 
> costs) and the available subscriptions vary slightly dependent on payment 
> type (direct debit, card, cheque etc...). 
>
> The subscriptions have a lot of different fields for each subscriptions so 
> I'm not clear on how best to represent this in django - one large model or 
> split into smaller models.
>
> Firstly,  each supplier will have multiple magazines - to keep the data 
> normalised should the suppliers be kept in a separate table/model separate 
> to the subscriptions table? How will this impact performance when having to 
> join the data back together when querying a list of subscriptions. 
> (e.g. similarly for payment types of which there are only 4 should these 
> be pulled out into a separate table? and regions)
>
> There will be a form field for: 
> supplier
> payment type,
> region,
> should a separate model be made for these 3 fields to ease with making the 
> form and how should that tie into the above tables (if they should be 
> separated? Should I make e.g. an Input model class with ForeignKeys to each 
> of the separate tables?). 
>
> Thanks.  
>
>
>

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

Running a live Django site

[JJ Zolper]

All,

In an effort to continue to push the Django community towards a point where 
we provide our developers with more information on how to run a live Django 
site, I would like to again share the High Performance Django Videos 
Kickstarter:

https://www.kickstarter.com/projects/1704706557/high-performance-django-videos

If you are able to become a backer please do.

We need to continue to push Django towards being the ultimate web developer 
platform.

Thanks,

JJ

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

Re: Locking / serializing access to one element in database

[Carsten Fuchs]

Hi Collin, hi all,

Am 27.10.2015 um 19:56 schrieb Collin Anderson:

Yes, an exception will be raised.


Thinking further about this, all we need is a method that gives us an exception if we 
accidentally create a second object when in fact only one is wanted. Your suggestion 
with manually dealing with the PKs and using .save(force_insert=True) is one method to 
achieve that, another one that works well for me is using an (application-specific)


unique_together = (year, month)

constraint, which achieves the desired result (guarantee uniqueness where required, 
raise an exception otherwise) without having to manually deal with PKs.


Alas, I wonder how to proceed to complete the solution. As I find it simpler to deal 
with the above mentioned unique_together rather than with coming up with a PK based 
solution, I refer to my original code from [1], which was:



try:
mm = TestMonthModel.objects.select_for_update().get(jahr=Jahr, 
monat=Monat)
except TestMonthModel.DoesNotExist:
mm = TestMonthModel(jahr=Jahr, monat=Monat)

# A *long* computation, eventually setting fields in mm and save:

mm.value = 123
mm.save()


Combining everything from this thread, this could be changed into this code 
(pseudo-code, not tested):



while True:
try:
mm = TestMonthModel.objects.select_for_update().get(jahr=Jahr, 
monat=Monat)
break   # Got what we wanted!
except TestMonthModel.DoesNotExist:
try:
# Create the expected but missing instance.
# No matter if the following succeeds normally or throws
# an Integrity error, thereafter just restart the loop.
TestMonthModel(jahr=Jahr, monat=Monat).save()
except IntegrityError:
pass

# A *long* computation, eventually setting fields in mm and save:

mm.value = 123
mm.save()


Afaics, this solves the problem, but it also feels quite awkward and I wonder if there 
is a more elegant solution.


Comments? Does this sound reasonable at all?

Best regards,
Carsten

[1] https://groups.google.com/forum/#!topic/django-users/SOX5Vjedy_s

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

MySQL queries-connection to django

[Sid]

I am new to DJANGO...
so i have installed django,python and using Visual studio as interface,
so my question is I have database name :*siddharth*  in sql server: 
*63-W7-MJ021R04\ALMDATA* i want to connect my database(siddharth) to django 
using settings.py, But i am not understanding how to do it
There are any other installations I have to do it to connect or I can use 
my database directly.
Can anyone please tell me the procedure it wil be very helpful

Your help is much appreciated.
Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/11363af6-28e1-43e4-bbad-40aea634e23c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL queries-connection to django

[Mike Dewhirst]

On 29/10/2015 7:00 AM, Sid wrote:

I am new to DJANGO...


You can connect to your database using Django but first Django needs to 
have a model of each table in your database so it knows what to look 
for. https://docs.djangoproject.com/en/1.8/howto/legacy-databases/


There is a management command which will analyse your database and 
automatically create those models. 
https://docs.djangoproject.com/en/1.8/howto/legacy-databases/#auto-generate-the-models


But if you are new to Django it would be best to come up to speed with a 
broader knowledge of the way things work. There is an excellent tutorial 
... https://docs.djangoproject.com/en/1.8/ ... which will take you step 
by step through the general learning curve.


Welcome and good luck

Mike



so i have installed django,python and using Visual studio as interface,
so my question is I have database name :*siddharth* Â in sql server:Â
*63-W7-MJ021R04\ALMDATA* i want to connect my database(siddharth) to
django using settings.py, But i am not understanding how to do it
There are any other installations I have to do it to connect or I can
use my database directly.
Can anyone please tell me the procedure it wil be very helpful

Your help is much appreciated.
Thanks

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
.
To post to this group, send email to django-users@googlegroups.com
.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/11363af6-28e1-43e4-bbad-40aea634e23c%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 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/56318FE0.7000800%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.