Hey Jeff, your email client line-wrapped your patch. Would you resend as an attachment or inline without the line wrapping?
"Jeff Linwood" <[EMAIL PROTECTED]> writes: > Hi, > > I was trying to make sure I understood how inheritance worked in Torque, so > I read up on the subject, and wrote some additional documentation for the > user guide to replace the small section there. I'll try and work on the > Class Hierarchy section next. > > Index: xdocs/user-guide.xml > =================================================================== > RCS file: /home/cvspublic/jakarta-turbine-torque/xdocs/user-guide.xml,v > retrieving revision 1.6 > diff -u -r1.6 user-guide.xml > --- xdocs/user-guide.xml 8 Nov 2001 15:56:52 -0000 1.6 > +++ xdocs/user-guide.xml 31 May 2002 08:05:57 -0000 > @@ -386,18 +386,60 @@ > > </section> > > -<section name="The Object Relational Map"> > +<section name="Inheritance and the Object Relational Map"> > > <p> > > - The OM/Peer (Torque) system can map a class hierarchy into a single > table. > - This is 1 of 3 methods generally described in object-relational mapping > - designs. Its benefits include that it does not require joins in order to > - gather the attributes for a single object. It falls short in modelling a > - class hierarchy where the related classes have a non intersecting > collection > - of attributes, as in this case a row in the table will have several null > - columns. > + Torque can handle object-oriented inheritance. There are generally > + considered to be 3 methods of object-relational mapping designs. Torque > + uses one of the fastest, mapping all objects in a class hierarchy to a > + single table. All attributes for every class in the hierarchy are stored > + in the table. Consider an abstract ComputerComponent class that has > Monitor > + and Keyboard subclasses. There would only be one table - both Monitor and > + Keyboard objects would be persisted to the same place. The table would > + consist of all ComputerComponent attributes, any unique Monitor > attributes, > + and any unique Keyboard attributes. Keyboard table rows would have NULL > for > + any unique Monitor data columns, and vice versa. > + > +</p> > +<p> > + > + The other fast method is to map each concrete class to a distinct > + table. Every object stores all attributes in a single row in the class > table. > + An example would be that if we had a Kitchen class that inherited from > Room, > + two tables would be needed for storage. The Kitchen table would contain > all > + of the columns of the Room table, plus any additional data columns needed > to > + describe the additional Kitchen attributes. > + > +</p> > +<p> > + > + The slowest, but most object-oriented method is to store each class in > its > + own table. Only attributes that are added to a derived class are stored > in > + its table. The persistence layer would need to join tables to read an > object > + out of storage. Saving objects would be more complex, because objects > will > + need to be distributed across multiple tables. For our Kitchen and Room > + example, there would also be two tables, Kitchen and Room, but the > Kitchen > + table would only contain those attributes which weren't part of the Room > + class. > + > +</p> > +<p> > + > + One of the advantages of the first method (the one Torque uses) is that > it > + does not require joins like the third method described above. Another > + advantage is that the data model is easier to maintain than the second > + method. It falls short in modelling a class hierarchy where the related > + classes have a non intersecting collection of attributes, as in this case > + a row in the table will have several null columns. > + > +</p> > +<p> > > + For more information, visit Scott Ambler's excellent web site, > + <a href="http://www.ambysoft.com/">AmbySoft.com</a>, where he discusses > + object mapping to relational databases. > + > </p> > > </section> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > SPAM: ---- Start SpamAssassin results > SPAM: -5 hits, 5 required; > SPAM: * -5.0 -- BODY: Contains what looks like a patch from diff -u > SPAM: > SPAM: ---- End of SpamAssassin results -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
