> Yes, doing this as a trigger would make sense... Couldn't say it better myself (orly), so:
"Database constraints and/or stored procedures make the validation mechanisms database-dependent and can make testing and maintenance more difficult. However, if your database is used by other applications, it may be a good idea to use some constraints at the database level. Additionally, database-level validations can safely handle some things (such as uniqueness in heavily-used tables) that can be difficult to implement otherwise" http://edgeguides.rubyonrails.org/active_record_validations_callbacks.html On Thu, Sep 23, 2010 at 3:34 PM, Mikel Lindsaar <raasd...@gmail.com> wrote: >> Is there much speed differences between using before/after filters versus >> using observers? Is one faster than the other from experiences? > > None. It all still happens in the same thread. It is just a programming > idiom. > > Unless you redesign your app to handle multiple threads that is.... > >> Or is this sort of thing is much better handled internally in the db through >> triggers and stored procedures (which would be a shame as I think's rail's >> approach to it is quite nice..) > > Yes, doing this as a trigger would make sense, as it allows the data to > return and rails to get on with its job and let the database handle the > auditing and compliance (which, by the way, is something that transactional > databases are VERY good at). > > Using Rails for all this back end stuff is actually violating a bit of your > MVC in my view. The model doesn't really need to know about caching values > in the database to speed up future requests. > > Having said that, I feel your pain. I had a similar situation, but with > multiple databases and I had no choice but to put all that "after update do > all this caching stuff" in the view. > > However, I did manage to split a fair bit out into worker processes, which is > another option you have. > > Regards > > > Mikel > http://rubyx.com/ > http://lindsaar.net/ > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-ocea...@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- http://awesomebydesign.com -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.