No, this is not a real Sinatra error :).
This is the personal homepage of Elad Meidar, a web developer and an entrepreneur specializing in Ruby on Rails. I hang around in Israel, and i am currently having the best time of my life over at Fiverr.com
I am a proud member of RailsBridge, Helping new Rails developers get into our world and also contributed a few Patches to the Ruby on Rails core.
Single Table inheritance. Lot’s of developers i talk to seem to hate the concept of STI and claim that it’s “java-ish” and something that should be avoided on all costs.
Generally i would spend me time explaining to that person why STI is a legitimate design pattern which can be useful and correct when being used in the right place and not as a “super solution for everything”, but a recent post named The Rails Code Quality Checklist recently bashed STI and surprisingly (imo, at least) got pretty good responses from people around.
Any case of a misused design pattern can be tagged as a “bad practice”, and the one to blame for it is usually the developer/programmer, and not the design pattern. I thought i might take a swing at this mayhem and maybe try to clear out some stuff about STI and best usage practices in rails:
STI is a design pattern that is aimed to allow multiple ORM classes to share the same database table in case they share a large base of common attributes (columns) and to represent an inheritance functionality in a relational DBMS. The main plus of this design pattern is that you don’t have to create several tables that have common columns, you just use a single table to host all your models and by that, DRYing up your database infrastructure.
Let’s say we have a `Cat` and a `Lion` classes. It would make perfect sense to use a single table inheritance in this case since we all (should) know that a lion is a kind of a cat.
Since there is almost a complete overlapping between those 2 models’ attributes (although they still differ in concept and may have different methods), it will be a smart choice to use STI in this case.
This is a bad example of an STI implementation:
Although Cat and Human can both be considered as Animals, they overlap each other in a very small number of attirbutes. As you can see `highschool_name` and `married_since` are both attributes that has no meaning when we are referring to a Cat instance, on the other hand `last_visit_at_the_vet` and `fur_color` are useless to a Human instance. Those attributes, although unnecessary, are also populated when you access the table.
If you have too many of those unnecessary fields, this may lead to bulky queries and lousy database performance, and of course, blaming STI.
Of course both of my examples could have been solved easily in other ways as you suggests (if one prefers that).
Point is, that STI is not more “evil” than overusing plugins, super-sized controllers, no cacheing or no testing. It’s yet another thing you need to know when and how to use.
You're seeing this error because I think it is funny.