# Help with Radiant/Rails Implementation **URL:** \ **Category:** Radiant CMS\ **Created:** [November 19, 2008, 8:00pm UTC](https://www.ruby-forum.com/t/help-with-radiant-rails-implementation/153648 "2008-11-19T20:00:28Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![mahadewa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/9e8a1a/32.png) [@mahadewa](https://www.ruby-forum.com/u/mahadewa)\ **Post date:** [November 19, 2008, 8:00pm UTC](https://www.ruby-forum.com/t/help-with-radiant-rails-implementation/153648/1 "2008-11-19T20:00:28Z")
I’m stumped and could use some help/advice – time to show your mad hackr skillz… Please forgive the length, there’s some needed background involved. ## Background SnS TextAsset models track their dependencies (each model parses its content and identifies \ or \ tags within). Easy. Then, when any model is updated, it announces this to all the other instances who check their dependencies and, if they depended on the updated model, adjust their own effectively\_updated\_at date. So far, still easy. ## The Problem Saving the effectively\_updated\_at date – not so easy. TextAsset models have callbacks – none of which should fire when only saving effectively\_updated\_at. Specifically, these are: ``` * Rails automatic timestamps (created_at, updated_at) * before_update and before_create callbacks (via Radiant's UserActionObserver to set created_by and updated_by) * My own before_save callback which parses the content to update its own dependencies (mentioned above) * My own after_save callback to announce to the other models that this one's been changed (mentioned above) ``` ## Current Solution The current solution is to store effectively\_updated\_at in a separate model with a has\_one relationship to its TextAsset. That way changes to the date are done directly through that sub-model and so doesn’t trigger the callbacks on the related TextAsset. This works but it _really_ bugs me having a separate table just for one field (a field that really belongs to another model). ## Help? Can anyone think of some clever solution that will let me move this attribute into TextAsset? How could I update and save a TextAsset’s effectively\_updated\_at attribute without waking up those callbacks? Or am I just being too picky? ## Ideas I’m open to anything here, really. My current ideas include: ``` * Make the TextAsset model explicitly handle all the above callbacks (no more auto timestamps, no more using Radiant's built-in observers). And then, in those callbacks, inspect an instance variable flag (say, @exit_callbacks) to end each routine. It's a bit messy but it also replaces some mess in dealing with the extra table. Mostly I don't like that it ignores Radiant's and Rails built-in tools. I'm also not sure how to make current_user available to a TextAsset (but that's probably not hard). * Add some way to disable callbacks on a particular instance (like maybe: http://github.com/cjbottaro/without_callbacks/tree/master). Seems neat but also sounds like a lot of code for one attribute. I've never used it either so I'm not sure how reliable it is or if it's solid across different Radiant/Rails versions. * Save to the effectively_updated_at column directly using the ActiveRecord's #connection method and SQL commands. Never done this before and it sounds like, well, yuck (but maybe I don't understand it well enough either). And could this even be done in a db-agnostic way? * Your idea here... ``` Thanks, Chris ---
**Author:** ![mahadewa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/9e8a1a/32.png) [@mahadewa](https://www.ruby-forum.com/u/mahadewa)\ **Post date:** [November 19, 2008, 8:16pm UTC](https://www.ruby-forum.com/t/help-with-radiant-rails-implementation/153648/2 "2008-11-19T20:16:25Z")
Chris P. wrote: > - Your idea here… Probably way out on a limb here (blame it on the time), but how about keeping that 1 table for that 1 column! OK, before you relegate it to Junk Mail 🙂 here’s an explanation: If I remember correctly (and I may be completely wrong), SnS supports certain types of extensions? If that’s the case, then it could be that all extensions using/ relying on SnS can assume the existence of this 1 table for storing information that is updated via callbacks and is intended to bypass all the other callbacks that you mentioned? (Even if you’re not supporting extensions, this could be a model/ table that general extensions can use for storing exactly this kind of thing). Cheers Mohit.