Piotrek Okoński's Profile

AFAIK Foundatiom overwrites style for table tags.

https://github.com/pokonski/public_activity/wiki/%5BHow-to%5D-Use-custom-fields-on-Activity

You can very much do this. We have a symbol syntax for this:

tracked owner: :user

this will execute the user association on the tracked object.

Not sure what you mean. Do you want to find activities with a specific owner?

Just to reply, it works for a couple of months now on stable :)

Yes, you can. You can freely extend the Activity model with additional columns and methods from other gems. See the Common examples section in README.

Obviously don't forget about fragment caching. This will save a lot of time on rendering and database hits.

You can write JOIN clauses that filter the activities which do not have the trackable association. This is more of a database question, than Ruby.

You can still display attributes this way:

• use params hash to cache attributes you want to display even when tracked object is removed
• do not actually remove the objects but set their attribute removed to true (more refactoring required)

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.