If I run makemigrations (once, twice, 20 times) it will always output:
Migrations for 'acb_coins':
0003_auto_20140129_1947.py:
- Alter field last_sync on coin
Model:
class Coin(models.Model):
name = models.CharField(max_length=80)
short_name = models.CharField(max_length=4)
rpc_address = models.CharField(max_length=30)
rpc_port = models.IntegerField(max_length=5)
balance = models.DecimalField(decimal_places=10, max_digits=15)
last_sync = models.DateTimeField(default=datetime.now())
--
Ticket URL: <https://code.djangoproject.com/ticket/21905>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
You don't want to be using datetime.now(): that gets evaluated at the time
the module is imported.
You'll want to use datetime.now
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:1>
* cc: info@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:2>
Comment (by taishi@…):
matt@ comment worked
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:3>
* keywords: migrate, migrations, datetime => check
* owner: => nobody
* component: Migrations => Core (Other)
Comment:
Given the confusion about passing `default` a `datetime` object instead of
a callable (which solves the problem), I'd like to propose the idea to add
a check to Django's check framework to make users aware of these problems
that might occur over the time when using `datetime.now()` instead of
`datetime.now`.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:4>
* stage: Unreviewed => Accepted
Comment:
Accepted in principle, but I'm not sure how this could be implemented.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:5>
Comment (by matheusrosa):
Why don't you use {{{auto_now=True}}} ? Every time you call save(), the
{{{last_sync}}} field gets updated with the latest date and time.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:6>
Comment (by russellm):
@mjtamlyn - This could be a job for the check framework. We could add a
field-level check on the value of default - if the value of default is
within some tolerance of now (e.g., within 10 seconds), raise a warning.
Since the checks are run almost immediately after the model is loaded, any
usage of datetime.now() would return the current date time (or as close as
practical). The only way this check would fail would be if someone
actually wanted *now*; so, we add it as a warning that can be silenced.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:7>
* easy: 0 => 1
Comment:
To that end, it's a pretty easy fix; marking as such.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:8>
Comment (by MarkusH):
Sounds like a plan, russellm. Do we want to get it into 1.7?
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:9>
Comment (by russellm):
@MarkusH - No reason it couldn't be in 1.7 - it's a minor fix. We just
need a patch :-)
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:10>
* status: new => closed
* resolution: => duplicate
Comment:
Duplicate of #21638
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:11>
* status: closed => new
* resolution: duplicate =>
Comment:
This ticket is not a duplicate at all. The intention is to add a check
command warning a user that `now()` instead of `now` as a field's default
value is probably not what they want.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:12>
* owner: nobody => mamun
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:13>
Comment (by AeroNotix):
@mamun patch incoming?
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:14>
* keywords: check => check nlsprint14
* owner: mamun => MarkusH
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:15>
* has_patch: 0 => 1
Comment:
Here's the pull request: https://github.com/django/django/pull/2346
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:16>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"9d8c73f6a1c636853a5c5013f21985d702b2301b"]:
{{{
#!CommitTicketReference repository=""
revision="9d8c73f6a1c636853a5c5013f21985d702b2301b"
Fixed #21905 -- Add info message if DateField or TimeField use a fixed
value
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:17>
Comment (by Florian Apolloner <florian@…>):
In [changeset:"11932e978f980846d2c3326ff070ece7e65bf75c"]:
{{{
#!CommitTicketReference repository=""
revision="11932e978f980846d2c3326ff070ece7e65bf75c"
Merge pull request #2346 from Markush2010/ticket21905
Fixed #21905 -- Add info message if DateField or TimeField use a fixed
value
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:18>
* status: closed => new
* resolution: fixed =>
Comment:
The implementation contains a bug. Here is the code that probably fixes it
https://github.com/django/django/pull/6749
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:19>
* status: new => closed
* resolution: => fixed
Comment:
Please file a new bug report instead of reopening this old fixed one.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:20>
Comment (by Chris Jerdonek):
> The implementation contains a bug. Here is the code that probably fixes
it https://github.com/django/django/pull/6749
FYI, this issue was recently rediscovered and fixed as part of #32966.
--
Ticket URL: <https://code.djangoproject.com/ticket/21905#comment:21>