A massive amount of link fixes (just links, almost no rewording)

[dbsrgits/DBIx-Class.git] / lib / DBIx / Class / Manual / Glossary.pod

diff --git a/lib/DBIx/Class/Manual/Glossary.pod b/lib/DBIx/Class/Manual/Glossary.pod
index 5cd25b6..334637d 100644 (file)
--- a/lib/DBIx/Class/Manual/Glossary.pod
+++ b/lib/DBIx/Class/Manual/Glossary.pod
@@ -55,7 +55,7 @@ condition between the tables.
 =head2 Relationship bridge
 
 A relationship bridge, such as C<many_to_many> defines an accessor to
-retrieve row contents across multiple relationships. 
+retrieve row contents across multiple relationships.
 
 The difference between a bridge and a relationship is, that the bridge
 cannot be used to C<join> tables in a C<search>, instead its component
@@ -66,26 +66,28 @@ relationships must be used.
 A Schema object represents your entire table collection, plus the
 connection to the database. You can create one or more schema objects,
 connected to various databases, with various users, using the same set
-of table L</Result class> definitions.
+of table L</Result Class> definitions.
 
 At least one L<DBIx::Class::Schema> class is needed per database.
 
-=head2 Result class
+=head2 Result Class
 
 A Result class defines both a source of data (usually one per table),
-and the methods that will be available in the L</Row> objects created
-using that source.
+and the methods that will be available in the L</Result> objects
+created using that source.
 
 One Result class is needed per data source (table, view, query) used
 in your application, they should inherit from L<DBIx::Class::Core>.
 
+See also: L<DBIx::Class::Manual::ResultClass>
+
 =head2 ResultSource
 
 ResultSource objects represent the source of your data, these are
 sometimes (incorrectly) called table objects.
 
 ResultSources do not need to be directly created, a ResultSource
-instance is created for each L</Result class> in your L</Schema>, by
+instance is created for each L</Result Class> in your L</Schema>, by
 the proxied methods C<table> and C<add_columns>.
 
 See also: L<DBIx::Class::ResultSource/METHODS>
@@ -99,25 +101,41 @@ fetch the data.
 
 See also: L<DBIx::Class::ResultSet/METHODS>
 
-=head2 Record
+=head2 Result
+
+Result objects contain your actual data. They are returned from
+ResultSet objects.  These are sometimes (incorrectly) called
+row objects, including older versions of the DBIC documentation.
 
-See Row.
+See also: L<DBIx::Class::Manual::ResultClass>
 
 =head2 Row
 
-Row objects contain your actual data. They are returned from ResultSet objects.
+See Result.
 
 =head2 Object
 
-See Row.
+See Result.
 
-=head2 join
+=head2 Record
+
+See Result.
 
 =head2 prefetch
 
+Similar to a join, except the related result objects are fetched and
+cached for future use, instead of used directly from the ResultSet.  This
+allows you to jump to different relationships within a Result without
+worrying about generating a ton of extra SELECT statements.
 
 =head1 SQL TERMS
 
+=head2 CRUD
+
+Create, Read, Update, Delete.  A general concept of something that can
+do all four operations (INSERT, SELECT, UPDATE, DELETE), usually at a
+row-level.
+
 =head2 Join
 
 This is an SQL keyword, it is used to link multiple tables in one SQL
@@ -130,9 +148,17 @@ to issue multiple SQL queries.
 A normalised database is a sane database. Each table contains only
 data belonging to one concept, related tables refer to the key field
 or fields of each other. Some links to webpages about normalisation
-can be found in L<DBIx::Class::Manual::FAQ|the FAQ>.
+can be found in L<the FAQ|DBIx::Class::Manual::FAQ>.
 
 =head2 Related data
 
 In SQL, related data actually refers to data that are normalised into
-the same table. (Yes. DBIC does mis-use this term).
+the same table. (Yes. DBIC does mis-use this term.)
+
+=head1 AUTHOR AND CONTRIBUTORS
+
+See L<AUTHOR|DBIx::Class/AUTHOR> and L<CONTRIBUTORS|DBIx::Class/CONTRIBUTORS> in DBIx::Class
+
+=head1 LICENSE
+
+You may distribute this code under the same terms as Perl itself.