All,
I know we have the wonderful ''console'' with Rails - and I know
we''ve
irbwith Ruby; but is there some means by which I can effectively write a
shell script and utilize my existing model classes within my Rails
application context?
The problem I''m trying to solve is notifying some set of subscribers
when a given model, let''s call it ''Asset'', is
updated. I know I can use
the after_update callback, but I don''t want to cloud my model with
subscription functionality; I''d rather have some scheduled job that
checks timestamps every x often and takes some action.
Ideally, I could just write code that reads:
# Somehow load up rails context <this is the part I''m missing>
assets = Asset.find(:all, :condtions => ["updated > ?",
sometimestamp])
assets.each {|asset| do_something}
Or, because I''m fairly new to Rails, I could be missing some simple
listener concepet, or really, I guess I could just go and write my own.
But, regardless, I know it will be useful for me to use a rails
application context in a script at some point so if I could get any
pointers, I''d be most grateful.
Thanks friends.
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Look into script/runner. It sounds like what you need. On Jan 1, 2008, at 4:08 PM, Cory Wilkerson wrote:> > All, > > I know we have the wonderful ''console'' with Rails - and I know we''ve > irbwith Ruby; but is there some means by which I can effectively > write a > shell script and utilize my existing model classes within my Rails > application context? > > The problem I''m trying to solve is notifying some set of subscribers > when a given model, let''s call it ''Asset'', is updated. I know I can > use > the after_update callback, but I don''t want to cloud my model with > subscription functionality; I''d rather have some scheduled job that > checks timestamps every x often and takes some action. > > Ideally, I could just write code that reads: > > # Somehow load up rails context <this is the part I''m missing> > assets = Asset.find(:all, :condtions => ["updated > ?", > sometimestamp]) > assets.each {|asset| do_something} > > Or, because I''m fairly new to Rails, I could be missing some simple > listener concepet, or really, I guess I could just go and write my > own. > But, regardless, I know it will be useful for me to use a rails > application context in a script at some point so if I could get any > pointers, I''d be most grateful. > > Thanks friends. > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
script/console does this for you. It loads the rails environment and allows you to do anything you would usually do in your models/controllers. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan Bigg wrote:> script/console does this for you. It loads the rails environment and > allows > you to do anything you would usually do in your models/controllers.Ryan - I get that, but what I want to do is basically schedule something on cron here...i.e., I won''t be sitting in front of a console to interact with it ;) I''m going to go read up on script/runner - sounds like that''s the ticket! -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ok, sorry I didn''t read your post correctly the first time. What''s wrong with putting it in the model? Models are designed to be fat. after_update sounds perfect for this! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Have you looked into backgroundrb http://backgroundrb.rubyforge.org/ ? Peace, Phillip On Jan 1, 2008, at 6:08 PM, Cory Wilkerson wrote:> > All, > > I know we have the wonderful ''console'' with Rails - and I know we''ve > irbwith Ruby; but is there some means by which I can effectively > write a > shell script and utilize my existing model classes within my Rails > application context? > > The problem I''m trying to solve is notifying some set of subscribers > when a given model, let''s call it ''Asset'', is updated. I know I > can use > the after_update callback, but I don''t want to cloud my model with > subscription functionality; I''d rather have some scheduled job that > checks timestamps every x often and takes some action. > > Ideally, I could just write code that reads: > > # Somehow load up rails context <this is the part I''m missing> > assets = Asset.find(:all, :condtions => ["updated > ?", > sometimestamp]) > assets.each {|asset| do_something} > > Or, because I''m fairly new to Rails, I could be missing some simple > listener concepet, or really, I guess I could just go and write my > own. > But, regardless, I know it will be useful for me to use a rails > application context in a script at some point so if I could get any > pointers, I''d be most grateful. > > Thanks friends. > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> What''s wrong with putting it in the model? Models are designed to be > fat. > after_update sounds perfect for this!Again - probably due to my lack of production-grade experience with rails; I''ve tended to keep my models focused only on the job at hand: validating data and moving data into/out of a database. It seems bit awkward to me to place application logic in my model, ie: def after_update self.subscribers.each {|subscriber| Notifier.deliver_notification subscriber} end Now that I''ve written it out - it doesn''t seem so bad after all - but it would seem this should be rolled up in my controller. There are going to be a number of times that I use this Asset and I won''t want to send updates out in every single case. After talking this through - adding it to the controller makes much more sense but now I fear blocking. Let''s say an asset has 1,000 subscribers and that deliver_notification method blocks for each send (I don''t know whether or not ActionMailer blocks); that''d tie up a thread for quite some time. Looks like I need to check out backgroundDrb. Thoughts? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi,> I know we have the wonderful ''console'' with Rails - and I know we''ve > irbwith Ruby; but is there some means by which I can effectively write a > shell script and utilize my existing model classes within my Rails > application context? >depending on the complexity and on your personal taste you could write a rake task (loading the rails environment as a dependency) or you could use script/runner either for calling a class method or for executing a .rb script. Either way your rails environment/models would be available. regards, javier ramÃrez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > There are going > to be a number of times that I use this Asset and I won''t want to send > updates out in every single case. >rails gives you a few methods like "update_without_callbacks" or "save_without_callbacks" with avoid the "after_update" or "before_save"-like functions. i doubt this will resolve your problem, but it was woth mentioning ; ) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 2, 2008 6:30 AM, Cory Wilkerson <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > What''s wrong with putting it in the model? Models are designed to be > > fat. > > after_update sounds perfect for this! > > Again - probably due to my lack of production-grade experience with > rails; I''ve tended to keep my models focused only on the job at hand: > validating data and moving data into/out of a database. > > It seems bit awkward to me to place application logic in my model, ie: > > def after_update > self.subscribers.each {|subscriber| Notifier.deliver_notification > subscriber} > end > > Now that I''ve written it out - it doesn''t seem so bad after all - but it > would seem this should be rolled up in my controller. There are going > to be a number of times that I use this Asset and I won''t want to send > updates out in every single case. > > After talking this through - adding it to the controller makes much more > sense but now I fear blocking. Let''s say an asset has 1,000 subscribers > and that deliver_notification method blocks for each send (I don''t know > whether or not ActionMailer blocks); that''d tie up a thread for quite > some time. > > Looks like I need to check out backgroundDrb. >Sending 1000 mails from live rails environment will be bad and will certainly tie up things. Try BackgrounDRb, its not terribly complex and should fit the bill. For any help, you can hop over to the mailing list and feel free to ask. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---