Revert TempExtlib ( b46b85376 ) - new Sub::Quote shipped
[dbsrgits/DBIx-Class-Historic.git] / lib / DBIx / Class / Storage / DBI / Replicated / Introduction.pod
index 6216be4..a95f3cd 100644 (file)
@@ -1,24 +1,22 @@
-package DBIx::Class::Storage::DBI::Replicated::Introduction;
-
 =head1 NAME
 
 DBIx::Class::Storage::DBI::Replicated::Introduction - Minimum Need to Know
 
 =head1 SYNOPSIS
 
-This is an introductory document for L<DBIx::Class::Storage::Replication>.
+This is an introductory document for L<DBIx::Class::Storage::DBI::Replicated>.
 
 This document is not an overview of what replication is or why you should be
-using it.  It is not a document explaining how to setup MySQL native replication
-either.  Copious external resources are available for both.  This document
+using it. It is not a document explaining how to setup MySQL native replication
+either. Copious external resources are available for both. This document
 presumes you have the basics down.
-  
+
 =head1 DESCRIPTION
 
-L<DBIx::Class> supports a framework for using database replication.  This system
-is integrated completely, which means once it's setup you should be able to 
+L<DBIx::Class> supports a framework for using database replication. This system
+is integrated completely, which means once it's setup you should be able to
 automatically just start using a replication cluster without additional work or
-changes to your code.  Some caveats apply, primarily related to the proper use
+changes to your code. Some caveats apply, primarily related to the proper use
 of transactions (you are wrapping all your database modifying statements inside
 a transaction, right ;) ) however in our experience properly written DBIC will
 work transparently with Replicated storage.
@@ -34,7 +32,7 @@ For an easy way to start playing with MySQL native replication, see:
 L<MySQL::Sandbox>.
 
 If you are using this with a L<Catalyst> based application, you may also want
-to see more recent updates to L<Catalyst::Model::DBIC::Schema>, which has 
+to see more recent updates to L<Catalyst::Model::DBIC::Schema>, which has
 support for replication configuration options as well.
 
 =head1 REPLICATED STORAGE
@@ -43,16 +41,16 @@ By default, when you start L<DBIx::Class>, your Schema (L<DBIx::Class::Schema>)
 is assigned a storage_type, which when fully connected will reflect your
 underlying storage engine as defined by your chosen database driver.  For
 example, if you connect to a MySQL database, your storage_type will be
-L<DBIx::Class::Storage::DBI::mysql>  Your storage type class will contain 
+L<DBIx::Class::Storage::DBI::mysql>  Your storage type class will contain
 database specific code to help smooth over the differences between databases
 and let L<DBIx::Class> do its thing.
 
 If you want to use replication, you will override this setting so that the
-replicated storage engine will 'wrap' your underlying storages and present 
+replicated storage engine will 'wrap' your underlying storages and present
 a unified interface to the end programmer.  This wrapper storage class will
 delegate method calls to either a master database or one or more replicated
 databases based on if they are read only (by default sent to the replicants)
-or write (reserved for the master).  Additionally, the Replicated storage 
+or write (reserved for the master).  Additionally, the Replicated storage
 will monitor the health of your replicants and automatically drop them should
 one exceed configurable parameters.  Later, it can automatically restore a
 replicant when its health is restored.
@@ -64,7 +62,7 @@ Additionally, if you need high data integrity, such as when you are executing
 a transaction, replicated storage will automatically delegate all database
 traffic to the master storage.  There are several ways to enable this high
 integrity mode, but wrapping your statements inside a transaction is the easy
-and canonical option. 
+and canonical option.
 
 =head1 PARTS OF REPLICATED STORAGE
 
@@ -131,13 +129,13 @@ one that makes sense.
 'balancer_args' get passed to the balancer when it's instantiated.  All
 balancers have the 'auto_validate_every' option.  This is the number of seconds
 we allow to pass between validation checks on a load balanced replicant. So
-the higher the number, the more possibility that your reads to the replicant 
+the higher the number, the more possibility that your reads to the replicant
 may be inconsistent with what's on the master.  Setting this number too low
 will result in increased database loads, so choose a number with care.  Our
 experience is that setting the number around 5 seconds results in a good
 performance / integrity balance.
 
-'master_read_weight' is an option associated with the ::Random balancer.  It
+'master_read_weight' is an option associated with the ::Random balancer. It
 allows you to let the master be read from.  I usually leave this off (default
 is off).
 
@@ -171,14 +169,14 @@ will find L<MySQL::Sandbox> an easy way to set up a replication cluster.
 
 And now your $schema object is properly configured!  Enjoy!
 
-=head1 AUTHOR
-
-John Napiorkowski <jjnapiork@cpan.org>
+=head1 FURTHER QUESTIONS?
 
-=head1 LICENSE
+Check the list of L<additional DBIC resources|DBIx::Class/GETTING HELP/SUPPORT>.
 
-You may distribute this code under the same terms as Perl itself.
+=head1 COPYRIGHT AND LICENSE
 
-=cut
+This module is free software L<copyright|DBIx::Class/COPYRIGHT AND LICENSE>
+by the L<DBIx::Class (DBIC) authors|DBIx::Class/AUTHORS>. You can
+redistribute it and/or modify it under the same terms as the
+L<DBIx::Class library|DBIx::Class/COPYRIGHT AND LICENSE>.
 
-1;