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? If it's 100% necessary to move the type calculation into the DB, triggers could accomplish much the same thing.
But maybe I'm missing something - 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), but that seems exceptionally unlikely. --Matt Jones On Jun 29, 7:12 am, bvdb <[email protected]> wrote: > Hello, > we have a problem in a CMS project that we believe is basic for RoR > developement and could concern others as well - or have already: > > RoR implements the 'Single Table Inheritance' (STI) > Pattern:http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html > > .. through its 'ActiveRecord' ORM. > The Fowler example mentions a 'type' column and RoR implements this > directly - which we consider inconsistent with DB abastraction: > It forces a 'type' column in the database following the application - > instead of the application asking the DB to derive the type _property_ > from immanent record properties. > > Practically, we would like to have a database function or condition to > control the type. > As a first step this can be done like this: > Select *, CASE WHEN some_condition THEN 'a' ELSE 'b' END AS type > FROM table1; > > We could define this as a view and put ut in a RoR model. > Problem is RoR can not tell a real table from a view (another > deficiency IMO) - and will try to UPDATE or INSERT the view which > fails. > > So what we'd need is a more flexible way to define STI, or maybe a way > to define a different Table for SELECTs (here a DB-view) in a model > than for UPDATEs and INSERTs. > > Has anybody done this before or what are your proposals for a solution? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
