Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What! I won't be able to sleep now! : )
    • ... sucking up to your rich uncle.

      Where there's a will, there's a relative.

      Seriously, the book was suggesting using other tables for subclasses and foreign key constraints against the original table. This, however, can lead to very clumsy code, though in practice, this is what is generally done. What if you want to save changes to a class? You class code needs to keep track of all tables which are affected and update them accordingly. I've done this and it can get quite complicated.

      That being said, the original relational model (not what we find in databases today) solves this problem trivially. Let's say that you have an Animal relation (sort of like a table) and a Mammal relation. How would Mammal inherit from Animal?

      What you could do is rename Mammal to _Mammal and make the subclass by writing a join which selects all of the relevant data from Animal and _Mammal into a new relation called Mammal. In the original relational model, the new relation is ... wait for it ... a relation! It's completely identical in behavior to the relations it's derived from and you can select from it, write to it, delete from it and have those changes appear in the original relations.

      SQL databases don't handle this very well but David Wheeler's module Object::Relation [cpan.org] does just that by using triggers and rules on either PostgreSQL or SQLite views (MySQL still doesn't support this) to allow you to treat views as tables. Thus, you can compose classes into a view and act like all of your data for a class is stored in a single table, regardless of how many underlying tables there are. It's quite slick, but it's not documented terribly well.

      Disclaimer: I did a fair amount of hacking on that code, so I may be biased. All credit for good stuff there belongs to David.