Sent from my iPhone
On Nov 14, 2010, at 4:02 PM, Matt Jones <[email protected]> wrote: > > On Nov 13, 2010, at 2:48 PM, Peter Booth wrote: > >> >>> I see a couple of options: >>> >>> 1) STI, aka Single Table Inheritance. This means that a single database >>> table holds all the attributes for all of the different types of objects, >>> and one column is used to hold the "type". This generally just means that >>> some columns are unused in some objects. See >>> http://cookbook.hobocentral.net/recipes/23-using-single-table-inheritance-sti-models >>> for a recipe on how to use STI. (Note that there may be an issue using >>> STI with Hobo on Ruby 1.9.2 -- Ruby 1.8.7 works.) >> >> I worked on an app that used STI for a model. This was a table whose size >> was proportional to 100x number of registered users. So as the userbase grew >> we had millions of rows that all include OneVeryLongCamelCaseClass and >> AnotherVeryLongCamelCasedClass. I couldn't see why ActiveRevord didn't use a >> numeric key instead of the classname. >> > > The problem I could imagine with a numeric key is that it still needs to be > mapped consistently to the correct class name, even in the face of > adding/removing classes from the possible choices. The AR method has the > advantage that a record's type can be readily determined when it's read from > the DB, without reference to any other tables or configuration. That makes complete sense, but when I start seriously thinking "what if I rename the classes A and B?" then I know I'm on shaky ground. I think it's just that rails is an awesome framework for the common case, but special cases will need some tweaking. > >>> >>> 2) rather than "has_many reviews", you can just use: >>> >>> has_many :amazon_reviews >>> has_many :yelp_reviews >>> def reviews >>> amazon_reviews+yelp_reviews >>> end >>> >>> then <collection:reviews> will automagically do the right thing and >>> correctly display the correct card for each review. >> >> This looks like a winner for my use case. Thank you very much, Hobo is >> increasing my enthusiasm for coding. > > One note on this: this method will load *all* the objects in both > associations, and won't work with pagination. In your application, that may > not be a problem - but it's worth being aware of. I'm already having problems with table size, they are probably due yo me being a server guy without much gui experience. For example: A Business has_many employees. My edit business page will create a new employee without a problem. But if I inadvertently create two business objects that represent the same thing, I might try to change the association on some employee objects from business 2 to business 1. If I use the employee index page to navigate to employee show, then my edit employee page has a select widget with upto 100 possible business to choose from- no guarantee I can select the one I need. Pragmatically, what do you do when you want to manage associations with 1000s or even 100,000s of records? > --Matt Jones > > -- > You received this message because you are subscribed to the Google Groups > "Hobo Users" 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/hobousers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
