Hello, On 30 Jun., 16:58, Matt Jones <[email protected]> wrote: > How is this different from setting the type attribute in a before_save > callback, other than moving the calculation from Ruby to SQL and doing > it on *every* query? ...
> ... is there a use case where caching > the type field like this wouldn't work? The only thing I can think of > is a situation where the object's type depends on *external* > parameters (eg, the current date), Of course the reason to do have the type derived from data in every query would be that the data might change, depending on user input, external phenomenon or another application accessing the same database. Abstracting data from application was one reason to use DBs in the first place. > If it's 100% necessary to move the type > calculation into the DB, triggers could accomplish much the same > thing. Triggers could also provide an "updateable view", but this would mean introducing quite some code into the DB just to facilitate a special application mechanism. If the information about 'type' is already given by other columns, an extra column is more like a cheap hack. Am I really the only one who sees a shortcoming here? And has no one ever wanted to access DB-Views with RoR (i.e. having the app understand that a certain relation is _not_ updateable)? --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
