From: John Napiorkowski <jjn1056@yahoo.com>
Date: Wed, 14 May 2008 17:57:57 +0000 (+0000)
Subject: documentation updates
X-Git-Tag: v0.08240~402^2~38
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=bca099a3feb17b1b4141ca0e55808d1bd95be103;p=dbsrgits%2FDBIx-Class.git

documentation updates
---

diff --git a/lib/DBIx/Class/Storage/DBI/Replicated.pm b/lib/DBIx/Class/Storage/DBI/Replicated.pm
index 27136b1..3bfbf60 100644
--- a/lib/DBIx/Class/Storage/DBI/Replicated.pm
+++ b/lib/DBIx/Class/Storage/DBI/Replicated.pm
@@ -43,15 +43,21 @@ one master and numerous slave database connections. All write-type queries
 database, all read-type queries (SELECTs) go to the slave database.
 
 Basically, any method request that L<DBIx::Class::Storage::DBI> would normally
-handle gets delegated to one of the two attributes: L</master_storage> or to
-L</current_replicant_storage>.  Additionally, some methods need to be distributed
+handle gets delegated to one of the two attributes: L</read_handler> or to
+L</write_handler>.  Additionally, some methods need to be distributed
 to all existing storages.  This way our storage class is a drop in replacement
 for L<DBIx::Class::Storage::DBI>.
 
 Read traffic is spread across the replicants (slaves) occuring to a user
 selected algorithm.  The default algorithm is random weighted.
 
-TODO more details about the algorithm.
+=head1 NOTES
+
+The consistancy betweeen master and replicants is database specific.  The Pool
+gives you a method to validate it's replicants, removing and replacing them
+when they fail/pass predefined criteria.  It is recommened that your application
+define two schemas, one using the replicated storage and another that just 
+connects to the master.
 
 =head1 ATTRIBUTES