Re: Loading fixtures inside a transaction

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

null=True and blank=False within model fields

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

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

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

Re: django 1.9, migrations SUCK

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

Re: Query annotation with date difference

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" -

Re: Query annotation with date difference

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

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

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

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

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

How do templates automatically convert dates to local timezone?

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

Loading fixtures inside a transaction

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

Re: Accessing session in Django models?

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

Accessing session in Django models?

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 =

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

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. >

Re: django 1.9, migrations SUCK

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

Re: django 1.9, migrations SUCK

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