Re: [mezzanine-users] Modifying behavior of TimeStamped `updated` timestamp for subclasses

2018-04-13 Thread Eduardo Rivas 
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 
 
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-users+unsubscr...@googlegroups.com 
.

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.

[mezzanine-users] Modifying behavior of TimeStamped `updated` timestamp for subclasses

2018-04-13 Thread Chris Hawes 
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-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.