Changes between Initial Version and Version 1 of Ticket #21798, comment 6


Ignore:
Timestamp:
Mar 13, 2014, 6:18:46 AM (11 years ago)
Author:
Sasha Romijn

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #21798, comment 6

    initial v1  
    11You are talking about `auto_now` and `auto_now_add`, right? There is no `auto_add_now`, as far as I know.
    22
    3 Provided that #21785 has resolved the migration issue, what is the actual need in deprecating this? Looking at the code, I see no reason why it should be invalid, or how it could cause issues. Yes, it would certainly be silly to add both `auto_now` and `auto_now_add`to a field, but I there are tons of silly field definitions that we still allow. For example, we also allow the combination of `auto_now_add` and `default`.
     3Provided that #21785 has resolved the migration issue, what is the actual need in deprecating this? Looking at the code, I see no reason why it should be invalid, or how it could cause issues. Yes, it would certainly be silly to add both `auto_now` and `auto_now_add`to a field, but there are tons of silly field definitions that we still allow. For example, we also allow the combination of `auto_now_add` and `default`.
    44
    5 A different situation would be if defining both would actually break in some cases, like the issue we resolved in #20484. But with #21785 is fixed, I see no similar situation here. When defining both, as far as I know, it behaves correctly and precisely as one would expect. Therefore, why should we disallow this combination?
     5A different situation would be if defining both would actually break in some cases, like the issue we resolved in #20484. But with #21785 fixed, I see no similar situation here. When defining both, as far as I know, it behaves correctly and precisely as one would expect. Therefore, why should we disallow this combination?
Back to Top