> 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.

Reply via email to