Re: Loading fixtures inside a transaction

[Simon Charette]

I believe it already does[1] as it is a requirement to support forward 
references.

Cheers,
Simon

[1] 
https://github.com/django/django/blob/5c63b3e5a797102d915e1683971517f747a28013/django/core/management/commands/loaddata.py#L68-L69

Le mercredi 3 août 2016 15:42:23 UTC-4, th...@copperleaf.com a écrit :
>
> Is it possible to have the `loaddata` manage command use a transaction 
> when loading a fixture?
>
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0abd506b-f760-4ce5-b202-f1380fe2664b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

null=True and blank=False within model fields

[Kevin Brown]

Within Django REST framework a discussion sparked 
 about 
how the combination of null=True and blank=False should be handled with 
validation. What side is right in the discussion isn't the question here.

Are there cases where it makes sense to set both `null=True`, which should 
allow for `None` to be set on a field, and to set `blank=False`, which does 
not allow blank values to be set on the field?

And what is considered to be a "blank value" for a field?

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/048e1e36-cf1f-4087-b989-d527994eb79b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing if a view have an html element with at least one attribute

[Fred Stluka]

  
  
Ludovic,

On my project, we have lots of test cases that do a GET or POST and

then check the returned HTML.  We use the BeautifulSoup HTML 
parser from our Django tests to avoid the types of errors you're 
getting with simple string comparisons.  I'm not sure if there any
pros/cons vs lxml, but it works great for us!

--Fred
  
  
  Fred Stluka -- mailto:f...@bristle.com --
  http://bristle.com/~fred/
  
  Bristle Software, Inc -- http://bristle.com -- Glad to be of
  service!
  
  Open Source: Without walls and fences, we need no Windows or
  Gates.
  
  

On 7/31/16 5:08 PM, Andreas Kuhne
  wrote:


  Jupp, thats about what I meant :-)


Probably the best way, if you don't want to check text.


Regards,


Andréas

  
  2016-07-31 18:01 GMT+02:00 ludovic
coues :
Currently,
  I am using lxml. More dependencies but it's the cleanest
  method I've found currently.
  I use it like that:
  
      from django.test import TestCase
      from lxml import etree
  
      class FormTest(TestCase):
          def test_input(self):
              response = self.client.get('/accounts/login')
              self.assertEqual(response.status_code, 200)
              doc = etree.HTML(response.content)
             
  self.assertEqual(len(doc.findall('.//input[@name="username"]')),
  1)
  

  
  
  2016-07-31 17:46 GMT+02:00 Andreas Kuhne :
  > 2016-07-31 15:59 GMT+02:00 ludovic coues :
  >>
  >> Oh, sorry. A bit of misunderstanding and
  miscommunication on my part.
  >>
  >> The exemple I gave is just a quick way to
  reproduce my problem. The
  >> real test use self.client, reverse, cast
  response.content to a string.
  >> What I gave is a minimal exemple.
  >>
  >> Also, I assumed you talked about comparing
  bit of html element, not
  >> the raw content returned by the view. I'm
  quite uneasy to have the
  >> test failing if a class is added or removed
  from the element. But yes,
  >> your solution work for the current state of
  the application.
  >>
  >> 2016-07-31 14:46 GMT+02:00 Andreas Kuhne :
  >> > 2016-07-31 13:56 GMT+02:00 ludovic coues
  :
  >> >>
  >> >> First, thanks for the suggestion.
  >> >>
  >> >> I just tried that, didn't work.
  >> >> Here is the test file I used:
  >> >>
  >> >>
  >> >>     from django.test import TestCase
  >> >>
  >> >>     class HTMLTestCase(TestCase):
  >> >>
  >> >>         def
  test_input_in_fieldset(self):
  >> >>             fieldset = """
  >> >>         
  >> >>             
  >> >>             
  >> >> maxlength="254" name="username"
  rows="3" type="text" required />
  >> >>         
  >> >>     """
  >> >>           
   self.assertInHTML('',
  fieldset)
  >> >>           
   self.assertInHTML('',
  fieldset)
  >> >>
  >> >>
  >> >> First input is to have a working
  exemple, second is taken as is from
  >> >> my view. Not closing the input in
  assertInHTML give an error `Couldn't
  >> >> find '
  >> >> errors with assertContains(*args,
  html=True)
  >> >>
  >> >> I could copy/past the input directly
  in my test but if the maxlength
  >> >> or class attribute change, the test
  will break. Taking the input
  >> >> directly from the django form will
  test if the django form is rendered
  >> >> in the view, not if the view is
  displaying a suitable form.
  >> >>
  >> >> 

Re: django 1.9, migrations SUCK

[ludovic coues]

Or, you could read either this thread or the doc and take advantage of
the django taking care of you.
Quoting the doc: "If the [choice] argument is a callable, it is
evaluated each time the field’s form is initialized."
That's why I suggested to add "lambda: " before the list
comprehension. To turn the value into a callable.

2016-08-03 16:17 GMT+02:00 Tom Christie :
> I'd suggest using `country = forms.ChoiceField(choices=[])` in the form
> declaration itself, and having the form `__init__()` method populate the
> *actual* set of choices. That way the allowable set of choices will always
> reflect whats currently in the DB at the point that the view runs.
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/288ec271-0118-46f5-93ba-089343e11cf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEuG%2BTb%2BL-xHbcf5FjiVSLgBKvrMAkohreO-F1eAhN%2BBGsCExQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Query annotation with date difference

[Constantine Covtushenko]

Sorry, I did not specify.
I have been using 'Postgresql' with 'psycopg2 v.2.6.2'.
They gave me those results.

Also here is a sql query given from log:
SELECT "test_app_entity"."id", "test_app_entity"."due_date",
"test_app_entity"."interval", (("test_app_entity"."due_date" -
'2016-08-03T21:31:58.325549+00:00'::timestamptz) /
"test_app_entity"."interval") AS "ratio" FROM "test_app_entity";
args=(datetime.datetime(2016, 8, 3, 21, 31, 58, 325549, tzinfo=),)

That is all that I can say at the moment.

On Thu, Aug 4, 2016 at 12:20 AM, Yoann Duriaud 
wrote:

> Thanks, unfortunately not so great on my side:
>
> I added in the query (forgetting the division for now):
>
> .annotate(ratio=ExpressionWrapper(F('due_date')-timezone.now(),
> DateTimeField()))
>
>
> which leads to the following statement in the query:
>
> ("contentstatus"."due_date" - 2016-08-03 21:05:10.743799+00:00) AS "ratio"
>
>
> This is not a valid SQL statement (at least for SQLite) and leads to the
> following error message when the query is evaluated:
>
> Exception Type:
>
> TypeError
> Exception Value:
>
>
> expected string or bytes-like object
>
>
> Any idea what I get this behavior?
>
> Yoann
>
>
> Le samedi 30 juillet 2016 22:41:21 UTC+2, Yoann Duriaud a écrit :
>>
>> Hello,
>> I would like to annotate a query with the following expression: ([Due
>> Date] - [Now])/[Interval]. [Due Date] and [Interval] are fields from the
>> database, while [Now] should be "equal" to timezone.now().
>>
>> So this would look like:
>> .annotate(ratio=(F('due_date')-timezone.now())/F('Interval'))
>>
>> but this does not work. Does someone know how the expression should be
>> written (if it is indeed feasible with Django ORM)?
>>
>> Thanks for your help!
>>
>> Yoann
>>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/038837c5-6b5b-4ae9-895a-b6b54282d978%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK52boX3b%2Bb6okqsKVXX%3DxQ7HUss9qL_BRbL8rpWFGE%3Ds2xL9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Query annotation with date difference

[Yoann Duriaud]

Thanks, unfortunately not so great on my side:

I added in the query (forgetting the division for now):

.annotate(ratio=ExpressionWrapper(F('due_date')-timezone.now(), 
DateTimeField()))


which leads to the following statement in the query:
 
("contentstatus"."due_date" - 2016-08-03 21:05:10.743799+00:00) AS "ratio"


This is not a valid SQL statement (at least for SQLite) and leads to the 
following error message when the query is evaluated:

Exception Type:

TypeError 
Exception Value: 


expected string or bytes-like object


Any idea what I get this behavior?

Yoann


Le samedi 30 juillet 2016 22:41:21 UTC+2, Yoann Duriaud a écrit :
>
> Hello,
> I would like to annotate a query with the following expression: ([Due 
> Date] - [Now])/[Interval]. [Due Date] and [Interval] are fields from the 
> database, while [Now] should be "equal" to timezone.now().
>
> So this would look like:
> .annotate(ratio=(F('due_date')-timezone.now())/F('Interval'))
>
> but this does not work. Does someone know how the expression should be 
> written (if it is indeed feasible with Django ORM)?
>
> Thanks for your help!
>
> Yoann
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/038837c5-6b5b-4ae9-895a-b6b54282d978%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How do templates automatically convert dates to local timezone?

[Robert Rollins]

Perhaps I wasn't clear. I know *what* Django does with timezone-aware 
dates. I just want to know *how* it does the conversion from the UTC-stored 
datetime in the DB to the localtime-displayed datetime in the templates. 
Which function(s) does the template system call to do the conversion?

On Wednesday, August 3, 2016 at 1:49:45 PM UTC-7, Constantine Covtushenko 
wrote:
>
> Hi Robert,
>
> You have touched a very simple but always confusing questions - storing 
> dates and showing them to users in different places.
>
> As I know Django uses that in very straightforward way.
> It always converts dates to UTC.
> Flow that converts them back to different users in different time-zones is 
> adjusted through settings.
>
> Please check settings for your testing environment.
> More information you can find on that `i18` documentation page 
> .
>
> Regards,
> I hope that helps.
>
>
> On Wed, Aug 3, 2016 at 11:36 PM, Robert Rollins  > wrote:
>
>> I'm writing tests that assert dates are being properly rendered on a 
>> certain page, but the tests are failing because the date value on the model 
>> object is in UTC, and the date is rendered in local time on the template. 
>> I'd like to run that date value through the same mechanism by which the 
>> template converts it to local time, so that my test does the same thing as 
>> the template.
>>
>> I've looked around, and unfortunately been unable to find the code that 
>> does the automatic conversion. The "date" template filter doesn't do it, 
>> and I'm too ignorant of the nitty gritty details of django template system 
>> to know what else I should be looking for. 
>>
>> Any help would be appreciated.
>>
>> -- 
>> 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/b4f5a0d6-8aea-47a9-969e-45c7a407a104%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/540c4257-7c82-434a-98a6-ab0fed40478f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How do templates automatically convert dates to local timezone?

[Constantine Covtushenko]

Hi Robert,

You have touched a very simple but always confusing questions - storing
dates and showing them to users in different places.

As I know Django uses that in very straightforward way.
It always converts dates to UTC.
Flow that converts them back to different users in different time-zones is
adjusted through settings.

Please check settings for your testing environment.
More information you can find on that `i18` documentation page
.

Regards,
I hope that helps.


On Wed, Aug 3, 2016 at 11:36 PM, Robert Rollins 
wrote:

> I'm writing tests that assert dates are being properly rendered on a
> certain page, but the tests are failing because the date value on the model
> object is in UTC, and the date is rendered in local time on the template.
> I'd like to run that date value through the same mechanism by which the
> template converts it to local time, so that my test does the same thing as
> the template.
>
> I've looked around, and unfortunately been unable to find the code that
> does the automatic conversion. The "date" template filter doesn't do it,
> and I'm too ignorant of the nitty gritty details of django template system
> to know what else I should be looking for.
>
> Any help would be appreciated.
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b4f5a0d6-8aea-47a9-969e-45c7a407a104%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK52boUGjOWLZfF3big60Ps1Ra%3DxjsZGMMy%3DTZ98Az2wMHhucg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How do templates automatically convert dates to local timezone?

[Robert Rollins]

I'm writing tests that assert dates are being properly rendered on a 
certain page, but the tests are failing because the date value on the model 
object is in UTC, and the date is rendered in local time on the template. 
I'd like to run that date value through the same mechanism by which the 
template converts it to local time, so that my test does the same thing as 
the template.

I've looked around, and unfortunately been unable to find the code that 
does the automatic conversion. The "date" template filter doesn't do it, 
and I'm too ignorant of the nitty gritty details of django template system 
to know what else I should be looking for. 

Any help would be appreciated.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b4f5a0d6-8aea-47a9-969e-45c7a407a104%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Loading fixtures inside a transaction

[thauk]

Is it possible to have the `loaddata` manage command use a transaction when 
loading a fixture?

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/965d6a76-a3db-4f3b-b8de-a0e8c30ff6a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Accessing session in Django models?

[Constantine Covtushenko]

Hi Neto,

As said in Documentation of 'limit_choices_to'

value for this key should be:
`Either a dictionary, a Q object, or a callable returning a dictionary or Q
object can be used.`

For your case these mean that you should use at least callable as 'use__id'
should be defined every Request/Response cycle.

Regards,


On Wed, Aug 3, 2016 at 7:25 PM, Neto  wrote:

> I have a field with *limit_choices_to*, and want it to be only filtered
> items related the account ('ID') user. How can I do this?
>
> Example (Does not work):
>
> class Car(models.Model):
> user = models.ForeignKey(User)
> color = models.CharField(max_length=200)
> typeo = models.ForeignKey(Typeo, limit_choices_to={'user__id': 
> session['user_id']})
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/8d2b4b10-83b9-489c-b834-31ddebc0c9df%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK52boXQ3T1Hb-OodKYLR%3DT66JDW76H_sBuRY0A33etJS-JFnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Accessing session in Django models?

[Neto]

I have a field with *limit_choices_to*, and want it to be only filtered 
items related the account ('ID') user. How can I do this?

Example (Does not work):

class Car(models.Model):
user = models.ForeignKey(User)
color = models.CharField(max_length=200)
typeo = models.ForeignKey(Typeo, limit_choices_to={'user__id': 
session['user_id']})

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8d2b4b10-83b9-489c-b834-31ddebc0c9df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Better style: from django.db import models vs from django.db.models import ...

[graeme]

On Monday, August 1, 2016 at 5:59:17 PM UTC+5:30, Michal Petrucha wrote:
>
> On Mon, Aug 01, 2016 at 05:09:37AM -0700, graeme wrote: 
> Either way is fine, using models.IntegerField 
> and forms.IntegerField just makes it more obvious what kind of 
> IntegerField it is you're referring to. 
>
 
I always have forms and models defined in separate files so it is a 
non-issue. If it is in models.py it is models.IntegerField etc.

>
> The only thing I can think of is that you might sometimes want to 
> define your own model field, in which you override the default 
> formfield; in that case, you'd need to have both model fields and form 
> fields in the same module, and it would be quite chaotic and unclear 
> which one you're referring to if you cherry-picked classes to import 
> instead of just importing the modules. 
>

Good point. In that particular file I would import models and forms for 
clarity. Probably put that in a separate file and import just my custom 
model field into models.py

>
> Cheers, 
>
> Michal 
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/51621217-b1ac-4d28-9188-9e807be30c51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.9, migrations SUCK

[Tom Christie]

I'd suggest using `country = forms.ChoiceField(choices=[])` in the form 
declaration itself, and having the form `__init__()` method populate the 
*actual* set of choices. That way the allowable set of choices will always 
reflect whats currently in the DB at the point that the view runs.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/288ec271-0118-46f5-93ba-089343e11cf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.9, migrations SUCK

['Tom Evans' via Django users]

On Fri, Jul 29, 2016 at 9:19 PM, Aztrock  wrote:
> Excellent, thanks
>
> This method i use from django 1.4, never have problem.
>

Apart from having to restart your application server each time you
added a country, sure, no problems.

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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1%2BTjwpfyOAFBY%2BBZrh_qAKCx86Y1D%2BBW821HVtYK44dCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.