Jon Hope's Profile

It's at least going to involve a select on every corresponding table included in the activities, there's really no way around that.

That's why I suggest saving an arbitrary hash of attributes on the activity object itself. 9 times out of 10 you only want, say, the ID and Name of the associated object in order to generate a link to it.

No sweat, let me know if I can help!

Public_activity looks like a great gem but we had some trouble with this approach in production. When tracking a number of changes on a number of models it bumped writes to the database quite substantially. Then when drawing back the associated objects on multiple activities there's a performance hit again.

We build our own solution for this called Redcrumbs.

It works in a very similar way but uses Redis as a backend. The benefits include superfast reads and writes but also Redis has an option to simply expire old keys, similar to memcached.

It also allows common attributes to be cached on the activity object, so that in 90% of cases the associated object doesn't have to be drawn from the primary database.

We've been using it in production to provide news feeds in our games for at least 6 months without a hitch.

Public_activity looks great for smaller sites though and there's an argument for keeping everything in the main database and on the same database structure.

Excellent! So handy. I'm outside the US so Stripe is no use to me. We're woefully behind in terms of SaaS billing options here (Ireland/UK).

Looking forward to the next installment on how to handle failure callbacks. :)