Re: Are we dropping auto_now and auto_now_add for 1.0?
I made this suggestion on the django board. @auto_now('updatted_on') @auto_add_now('submitted_date') def save(self): super(MyModel).save() I even have started coding it as I need SOME solution that is simple. One problem I have had is with edit_inline and auto_now where the entries are always updated in teh admin even if nothing was changed. Also there are sometimes when I want an auto_now on condition. So this all boils down to something like def auto_now(save, *field_names, **options): condition = None if 'condition' in options: condition = options['condition'] if not len(field_names): raise InvalidArgument, "Something..." save = save field_names = field_names def auto_now_decorator(object): if condition is not None: if not condition(object): return for name in field_names: setattr(object, name, datetime.datetime.now()) save(object) return auto_now_decorator def auto_add_now(save, *field_names, **options): base_condition = None if 'condition' in options: base_condition = options['condition'] def new_condition(object): ## add code to get models PK field from type(object). pk = 'id' if getattr(object, pk) is None: if base_condition is not None: return base_condition(object) return True return False options['condition'] = new_condition return auto_now(save, *field_names, **options) This would allow for things like: @auto_now('last_saved_on', 'other_field') @auto_now('updated_on', condition = lambda obj: fields_have_changed(object)) ## only set the datetime on new objects if the field is not already set... @auto_add_now('submitted_date', condition=lambda obj: obj.submitted_date is None) def save(self): ## some other custom code super(MyModel, self).save() To be honest this could be abstracted further where the dynamic value could be set lazy, (like in the previous post has on the model fields). I perfer having these as decorators so they can be added to ANY save 'like' method or on the form it's self. I also used the term 'dynamic' on purpose, as this is not a default value, but could be set to anything based on any of the other fields or any outside influence. There are problems with the above code, the PK issue is mentioned, but there are also issued with time vs data vs datetime vs strings, and giving proper errors for fields which do not exist. I would also want another option for doing backoff validation but that is for a separate post. I would love any feedback anyone has on this Idea. There are a number of projects I am working on that will need this (PyCon, python Jobs board, and 3 others), so I plan on doing a formal implementation starting soon. -Doug On Apr 6, 10:03 pm, Sean Perry <[EMAIL PROTECTED]> wrote: > On Apr 6, 2007, at 11:39 AM, David Larlet wrote: > > > > > > > 2007/4/6, Brian Beck <[EMAIL PROTECTED]>: > > >> On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote: > >>> It could be just me, but although i don't mind losing auto_*, it > >>> don't > >>> look very DRY in save. > > >>> I know it's only a few lines (like 4 ? for both options, not using > >>> default= for sake of keeping the logic together) but when lots of > >>> models > >>> have a cre_date and mod_date, those lines are repeated over and over > >>> again in save(). > > >> I agree. Using default= in place of auto_now_add is fine, but writing > >> a save() for every model that needs auto_now is just annoying. A > >> shortcut would be nice. > > > I agree with Brian. > > seems like it should be as easy as a function in contrib somewhere: > > def auto_now(amodel): > if not amodel.id: > amodel.created = datetime.datetime.now() > else: > amodel.modified = datetime.datetime.now() > > super(type(amodel), amodel).save() > > and in your model you have: > > save = contrib.auto_now > > When you have to add code to your save() method you could still call > auto_now(self). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
+1. Follows DRY. An AutoDateTimeField is very common. j On 4/6/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > > seems like it should be as easy as a function in contrib somewhere: > [snip] > > Another option is a trivial field subclass:: > > class AutoDateTimeField(models.DateTimeField): > def pre_save(self, model_instance, add): > return datetime.datetime.now() > > Jacob > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
> seems like it should be as easy as a function in contrib somewhere: [snip] Another option is a trivial field subclass:: class AutoDateTimeField(models.DateTimeField): def pre_save(self, model_instance, add): return datetime.datetime.now() Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On Apr 6, 2007, at 11:39 AM, David Larlet wrote: > > 2007/4/6, Brian Beck <[EMAIL PROTECTED]>: >> >> On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote: >>> It could be just me, but although i don't mind losing auto_*, it >>> don't >>> look very DRY in save. >>> >>> I know it's only a few lines (like 4 ? for both options, not using >>> default= for sake of keeping the logic together) but when lots of >>> models >>> have a cre_date and mod_date, those lines are repeated over and over >>> again in save(). >> >> I agree. Using default= in place of auto_now_add is fine, but writing >> a save() for every model that needs auto_now is just annoying. A >> shortcut would be nice. > > I agree with Brian. > seems like it should be as easy as a function in contrib somewhere: def auto_now(amodel): if not amodel.id: amodel.created = datetime.datetime.now() else: amodel.modified = datetime.datetime.now() super(type(amodel), amodel).save() and in your model you have: save = contrib.auto_now When you have to add code to your save() method you could still call auto_now(self). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
Did people feel that save() was a better solution because it's already a place where you have to put equivalent functionality for other fields? I don't know why, but defining my own save() always seems like a "big deal" that should be reserved for more complex stuff. What about a new attribute for all fields, something like: default_condition, where: - The default is set if default_condition(current_value) is True. - By default, default_condition is `lambda value: value is None`, this mimicks current behavior. So: # default_condition is True when created_date is None created_date = models.DateTimeField(default=datetime.now) # default_condition is always True, equivalent to auto_now=True updated_date = models.DateTimeField(default=datetime.now, default_condition=lambda value: True) And it's useful for other fields: minimum_of_zero = models.IntegerField(default=0, default_condition=lambda value: value < 0) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
2007/4/6, Brian Beck <[EMAIL PROTECTED]>: > > On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote: > > It could be just me, but although i don't mind losing auto_*, it don't > > look very DRY in save. > > > > I know it's only a few lines (like 4 ? for both options, not using > > default= for sake of keeping the logic together) but when lots of > > models > > have a cre_date and mod_date, those lines are repeated over and over > > again in save(). > > I agree. Using default= in place of auto_now_add is fine, but writing > a save() for every model that needs auto_now is just annoying. A > shortcut would be nice. I agree with Brian. Regards, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote: > It could be just me, but although i don't mind losing auto_*, it don't > look very DRY in save. > > I know it's only a few lines (like 4 ? for both options, not using > default= for sake of keeping the logic together) but when lots of > models > have a cre_date and mod_date, those lines are repeated over and over > again in save(). I agree. Using default= in place of auto_now_add is fine, but writing a save() for every model that needs auto_now is just annoying. A shortcut would be nice. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On Apr 2, 2:50 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > > I'm not sure if there's a ticket for this, but I remember talk about > > it being an unnecessary wart which was going to be removed eventually. > > Is it in the 1.0 plan? > > Yes, I'd like to drop those two options. > > auto_now can be accomplished with "default=datetime.datetime.now", and > auto_now_add can be accomplished with a custom save() method. > > Adrian It could be just me, but although i don't mind losing auto_*, it don't look very DRY in save. I know it's only a few lines (like 4 ? for both options, not using default= for sake of keeping the logic together) but when lots of models have a cre_date and mod_date, those lines are repeated over and over again in save(). Maybe a decorator or the dispatcher can help for all the models with automaticly filled cre and mod_date's. This could also be combined with things like last_modified_by_user and created_by_user. Cause to me it seems these are all standard (housekeeping) tasks which you would like to associate with a model and not repeat the code for it in every model. But i could be missing the point entirely :) Malcolm's 'It's Monday' comment could apply to me too ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On 4/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > I'm not sure if there's a ticket for this, but I remember talk about > > it being an unnecessary wart which was going to be removed eventually. > > Is it in the 1.0 plan? > > Yes, I'd like to drop those two options. > > auto_now can be accomplished with "default=datetime.datetime.now", and > auto_now_add can be accomplished with a custom save() method. well, if I see this correctly, both have to be implemented in save(). Default will only be used if you don't supply a value, where auto_now is used every time and cannot be overridden. that said, I would be happy without them as well ;) +1 on removing those options > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On Mon, 2007-04-02 at 09:21 +0800, Russell Keith-Magee wrote: > On 4/2/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > Is there an easy way to say "today - 3 days" just using the datetime > > module? I can't think of one off the top of my head that isn't as > > complex as LazyDate(), but that may be because it's Monday. > > How about: > > lambda : datetime.now() + datetime.timedelta(days=3) Yep, you're right. Must be Monday. :-( I withdraw my objection. Nuke it. Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On Mon, 2007-04-02 at 11:11 +1000, Malcolm Tredinnick wrote: [...] > At the moment LazyDate is useful in limit_choices_to and as a default > value. Scrub that last part. Wishful thinking on my part. It can't really be used as a default at the moment, because it doesn't have a __call__ method. Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On 4/2/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Is there an easy way to say "today - 3 days" just using the datetime > module? I can't think of one off the top of my head that isn't as > complex as LazyDate(), but that may be because it's Monday. How about: lambda : datetime.now() + datetime.timedelta(days=3) Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On Mon, 2007-04-02 at 09:00 +0800, Russell Keith-Magee wrote: > On 4/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > > I'm not sure if there's a ticket for this, but I remember talk about > > > it being an unnecessary wart which was going to be removed eventually. > > > Is it in the 1.0 plan? > > > > Yes, I'd like to drop those two options. > > > > auto_now can be accomplished with "default=datetime.datetime.now", and > > auto_now_add can be accomplished with a custom save() method. > > What about LazyDate? It seems to me that given > "default=datetime.datetime.now" is legal, LazyDate can be deprecated > as well. Is there an easy way to say "today - 3 days" just using the datetime module? I can't think of one off the top of my head that isn't as complex as LazyDate(), but that may be because it's Monday. At the moment LazyDate is useful in limit_choices_to and as a default value. I'd vote to move it into django/utils/dates.py so that it's more visible (it feels wrong in models/__init__.py, but that may just be my bad taste), but I'd like to keep it. Otherwise I'm pretty sure I'm going to end up rewriting it for myself. Cheers, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On 4/1/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > What about LazyDate? It seems to me that given > "default=datetime.datetime.now" is legal, LazyDate can be deprecated > as well. Yeah, I'd like to get rid of LazyDate, too. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On 4/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > I'm not sure if there's a ticket for this, but I remember talk about > > it being an unnecessary wart which was going to be removed eventually. > > Is it in the 1.0 plan? > > Yes, I'd like to drop those two options. > > auto_now can be accomplished with "default=datetime.datetime.now", and > auto_now_add can be accomplished with a custom save() method. What about LazyDate? It seems to me that given "default=datetime.datetime.now" is legal, LazyDate can be deprecated as well. Yours Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote: > I'm not sure if there's a ticket for this, but I remember talk about > it being an unnecessary wart which was going to be removed eventually. > Is it in the 1.0 plan? Oh, please, yes! I'd be inclined just to remove 'em wholesale and let things fail loudly, but if someone wants to work up a patch that issues a validation warning (and otherwise does nothing when those params are there) that's probably the right approach. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Are we dropping auto_now and auto_now_add for 1.0?
On 4/1/07, SmileyChris <[EMAIL PROTECTED]> wrote: > I'm not sure if there's a ticket for this, but I remember talk about > it being an unnecessary wart which was going to be removed eventually. > Is it in the 1.0 plan? Yes, I'd like to drop those two options. auto_now can be accomplished with "default=datetime.datetime.now", and auto_now_add can be accomplished with a custom save() method. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Are we dropping auto_now and auto_now_add for 1.0?
I'm not sure if there's a ticket for this, but I remember talk about it being an unnecessary wart which was going to be removed eventually. Is it in the 1.0 plan? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---