On Jul 3, 9:42 am, bvdb <[email protected]> wrote:
> 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.
Even the view method is going to end up binding the two together,
unless you plan on somehow returning *different* values for type
depending on the calling application.
> > 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.
Maybe I'm being dense, but it doesn't seem like any more "code in the
DB" than defining the view.
> If the information about 'type' is already given by other columns, an
> extra column is more like a cheap hack.
Or, as the computer scientists call it, "memoization". I'd presume
that the types involved change far less often than the data is
accessed.
> 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)?
Some Google searching shows that most of the discussion around views
and ActiveRecord focuses on either using updatable views or on doing
read-only stuff with non-updatable views. I did find the Class-table
Inheritance plugin, which may yield some insight for your project
(docs @ http://clti.rubyforge.org/). The biggest issue is that while
views are part of the SQL standard, the rules for updating are very DB-
specific. Since AR is targeted to be database-independent, the result
is totally ignoring the feature.
--Matt Jones
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
