Here are a few simple tips that will help you get your bearings with
DBIx::Class.
-=head2 Tables become ResultSources
+=head2 Tables become Result classes
-DBIx::Class needs to know what your Table structure looks like. You do that by
-defining L<DBIx::Class::ResultSource>s. Each table gets a ResultSource, which
-defines the Columns it has, along with any Relationships it has to other tables.
-(And oh, so much more besides) The important thing to understand:
+DBIx::Class needs to know what your Table structure looks like. You
+do that by defining Result classes. Result classes are defined by
+calling methods proxied to L<DBIx::Class::ResultSource>. Each Result
+class defines one Table, which defines the Columns it has, along with
+any Relationships it has to other tables. (And oh, so much more
+besides) The important thing to understand:
- A ResultSource == Table
+ A Result class == Table
(most of the time, but just bear with my simplification)
Setting up a ResultSet does not execute the query; retrieving
the data does.
+=head2 Search results are returned as Rows
+
+Rows of the search from the database are blessed into
+L<DBIx::Class::Row> objects.
+
=head1 SETTING UP DBIx::Class
Let's look at how you can set and use your first native L<DBIx::Class> tree.
For a complete overview of the available attributes, see
L<DBIx::Class::ResultSet/ATTRIBUTES>.
+=head1 NOTES
+
+=head2 Problems on RHEL5/CentOS5
+
+There is a problem with slow performance of certain DBIx::Class operations in
+perl-5.8.8-10 and later on RedHat and related systems, due to a bad backport of
+a "use overload" related bug. The problem is in the Perl binary itself, not in
+DBIx::Class. If your system has this problem, you will see a warning on
+startup, with some options as to what to do about it.
+
=head1 SEE ALSO
=over 4