Piotrek Okoński's Profile

This is more of a papertrail, not activity tracking.

Hi!

Can you tell what performance issues you have?

Would you like to discuss this further on Github Issues? This is really interesting, but querying for Activities with Redis requires a whole different process.

If you edit the object multiple times, then multiple Activities are created each time.

Ah yes, that makes sense.

There's even a Railscast about it, though quite old, but still applies http://railscasts.com/episodes/29-group-by-month

That's exactly what public_activity does, minus delaying. Also using delayed_job makes no sense, because it still has writes to the db, so you might as well write the activity. Better option is something redis based.

Good idea about delaying the activity creation!

Hi @iashraf. I'll prepare a wiki page for this and post the link here :)

Yes, this is ugly, but completely optional. You can do creation manually using #create_activity and only use #tracked to set defaults, if for example you know you will always need to cache recipe's name.

Exactly, that is the main reason params exists, to cache important attributes of associated objects. See http://rubydoc.info/gems/public_activity/PublicActivity/Tracked/ClassMethods#tracked-instance_method

All associations are polymorphic, so it is a hard topic. I personally cache whole pages of activities.

You make a good point about performance and storage. Redis is a good idea as backend - which I will look into.