[Catalyst-commits] r12420 - trunk/examples/CatalystAdvent/root/2009

Thu Dec 17 01:12:56 GMT 2009

Author: ribasushi
Date: 2009-12-17 01:12:56 +0000 (Thu, 17 Dec 2009)
New Revision: 12420

Modified:
   trunk/examples/CatalystAdvent/root/2009/17.pod
Log:
POD::XHTML sucks - doesn't understand L<...|...>

Modified: trunk/examples/CatalystAdvent/root/2009/17.pod
===================================================================

--- trunk/examples/CatalystAdvent/root/2009/17.pod	2009-12-17 00:43:59 UTC (rev 12419)
+++ trunk/examples/CatalystAdvent/root/2009/17.pod	2009-12-17 01:12:56 UTC (rev 12420)
@@ -124,15 +124,15 @@
 =head1 The Trick Revealed
 
 Just like being able to L<turn ResultSets into nested 
-structures|DBIx::Class::ResultClass::HashRefInflator>, L<DBIx::Class> can 
+structures|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultClass%3A%3AHashRefInflator>, L<DBIx::Class> can 
 turn such structures back to related rows. All you have to do is augment the 
 hashref you normally pass to L<DBIx::Class::ResultSet/create> with a 
 structure representing the related row(s), keyed off the B<relationship 
 name>. The structure will be either another hashref (for single-type 
-relationships i.e. L<belongs_to|DBIx::Class::Relationship/belongs_to>, 
-L<has_one|DBIx::Class::Relationship/has_one>, 
-L<might_have|DBIx::Class::Relationship/might_have>) or an arrayref of 
-hashrefs for L<has_many|DBIx::Class::Relationship/has_many> (relationship of 
+relationships i.e. L<belongs_to|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ARelationship#belongs_to>, 
+L<has_one|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ARelationship#has_one>, 
+L<might_have|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ARelationship#might_have>) or an arrayref of 
+hashrefs for L<has_many|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ARelationship#has_many> (relationship of 
 type multi).
 
 When the enlightened coworker did C<< ->create ($chunk) >> he effectively 
@@ -153,18 +153,18 @@
 
 which was properly taken apart and inserted in the appropriate tables using 
 the appropriate foreign keys as one would expect. In addition since 
-L<create()|DBIx::Class::ResultSet/create> is a single call, L<DBIx::Class> 
+L<create()|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet#create> is a single call, L<DBIx::Class> 
 takes care of making it atomic by dutifully wrapping the entire operation in 
-a L<transaction|DBIx::Class::Manual::Cookbook/TRANSACTIONS>.
+a L<transaction|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AManual%3A%3ACookbook#TRANSACTIONS>.
 
 The same logic applies to L<DBIx::Class::ResultSet/populate> which happily 
 accepts an arrayref of hashrefs as the creation argument. In fact you can 
 bootstrap a poor man's replication by simply dumping a 
-L<ResultSet|DBIx::Class::ResultSet> via 
+L<ResultSet|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet> via 
 L<DBIx::Class::ResultClass::HashRefInflator>, and feeding the result straight 
-back to L<create()|DBIx::Class::ResultSet/create>, using a 
-L<ResultSet|DBIx::Class::ResultSet> derived from the target 
-L<Schema|DBIx::Class::Schema/resultset>.
+back to L<create()|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet#create>, using a 
+L<ResultSet|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet> derived from the target 
+L<Schema|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ASchema#resultset>.
 
 =head2 But does it scale?
 
@@ -178,7 +178,7 @@
 
 Won't L<DBIx::Class> attempt to create the same producer several times? 
 Fortunately no: any creation attempt over a 
-L<belongs_to|DBIx::Class::Relationship/belongs_to> relationship will be 
+L<belongs_to|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ARelationship#belongs_to> relationship will be 
 executed via a L<DBIx::Class::ResultSet/find_or_create>, thus allowing 
 everything to just work. For the brave there is an L<example pushing all 
 conceivable limits|http://cpansearch.perl.org/src/FREW/DBIx-Class-0.08115/t/multi_create/torture.t>.
@@ -189,9 +189,9 @@
 
 =item
 
-Currently this works for L<create()|DBIx::Class::ResultSet/create> only. 
-While L<find_or_create|DBIx::Class::ResultSet/find_or_create> will be 
-executed on L<belongs_to|DBIx::Class::Relationship/belongs_to> relationships, 
+Currently this works for L<create()|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet#create> only. 
+While L<find_or_create()|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet#find_or_create> will be 
+executed on L<belongs_to|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3ARelationship#belongs_to> relationships, 
 the final goal is nothing more than new row creation. This means that e.g. 
 passing a nested structure to L<DBIx::Class::ResultSet/update_or_create> will 
 not do anything close to what you would expect.
@@ -200,12 +200,12 @@
 
 The returned object does not always have the proper related objects inserted 
 at the expected slots (similar to the effect of 
-L<prefetch|DBIx::Class::ResultSet/prefetch>). We need a good amount of tests 
+L<prefetch|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet#prefetch>). We need a good amount of tests 
 before we attempt to make this work as expected - patches welcome!
 
 =item
 
-The L<find_or_create|DBIx::Class::ResultSet/find_or_create> use mentioned 
+The L<find_or_create()|http://search.cpan.org/perldoc?DBIx%3A%3AClass%3A%3AResultSet#find_or_create> use mentioned 
 above can result in some strange behavior. Consider:
 
  my $cd_data = {


