Oh, this is a much better idea. I will give it a try. Thank you!

On Friday, 13 April 2018 12:54:46 UTC-4, Eduardo Rivas wrote:
>
> Haven't tried this but I think it should work. It is an extra DB table but 
> doesn't require monkey patching anything and it can leave in its own app:
>
> Create a new model called LastUpdate or TimeStamp, with a datetime field 
> and a generic relation 
> <https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#generic-relations>
>  
> to any model. Then use signals attached to the models you're interested in 
> to update_or_create LastUpdate instances when a model is saved according to 
> your criteria.
>
> Now you should have a reverse relation in BlogPost (and any model you 
> want) to get the LastUpdate instance. If that doesn't work you should still 
> be able to filter LastUpdate instances by ContenType and PK.
>
> On 2018-04-13 10:33 AM, Chris Hawes wrote:
>
> I want to display a timestamp on each BlogPost showing when the post was 
> last updated. My first attempt at this was to just show the `updated` 
> timestamp from the TimeStamped superclass. However, this timestamp is 
> bumped up every time the post is saved for any reason. For instance if a 
> user adds a comment, BlogPost gets saved in order to update its 
> comment_count field, and `updated` gets bumped as a result. That's no good.
>
> I also have two other RichText-TimeStamped classes that require similar 
> functionality. Since I own those classes, the obvious thing would be to 
> make an abstract superclass that adds a new modified timestamp field and 
> updates it appropriately on save.
>
> But what do I do about BlogPost? I don't own it so my options are limited, 
> and I am struggling to come up with a nice way to handle it. 
>
>    - I could add a field through EXTRA_MODEL_FIELDS and monkey patch 
>    BlogPost.save() to update it. But I would prefer to use the same logic for 
>    the other two classes as for BlogPost. 
>    - I could monkey patch TimeStamped.save(), but would have to put a 
>    super ugly hack so that it only affects the 3 subclasses that I care about.
>    - Subclassing BlogPost might be an option, but it would create a new 
>    table, which is not fun, plus I already have a bunch of existing blog 
> posts 
>    so I'm not sure offhand what I'd do about those.
>    
> I am wondering if anyone has a better idea? Is there a nice way to handle 
> cases like this that I am missing?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mezzanine-use...@googlegroups.com <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to