Sign in through GitHub

Please read for an updated status on RailsCasts:

Learn more or hide this

Piotrek Okoński's Profile

GitHub User: pokonski

Site: http://okonski.org

Comments by Piotrek Okoński

Avatar

AFAIK Foundatiom overwrites style for table tags.

Avatar

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.

Avatar

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

Avatar

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

Avatar

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.

Avatar

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

Avatar

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)
Avatar

This is more of a papertrail, not activity tracking.

Avatar

Hi!

Can you tell what performance issues you have?

Avatar

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.

Avatar

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

Avatar

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

Avatar

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.

Avatar

Good idea about delaying the activity creation!

Avatar

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

Avatar

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.

Avatar

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

Avatar

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

Avatar

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