[Bast-commits] r4022 - DBIx-Class-Fixtures/1.000/trunk/lib/DBIx/Class

[captainL at dev.catalyst.perl.org]

Author: captainL
Date: 2008-02-04 17:36:46 +0000 (Mon, 04 Feb 2008)
New Revision: 4022

Modified:
   DBIx-Class-Fixtures/1.000/trunk/lib/DBIx/Class/Fixtures.pm
Log:
added docs for relative date stuff

Modified: DBIx-Class-Fixtures/1.000/trunk/lib/DBIx/Class/Fixtures.pm
===================================================================
--- DBIx-Class-Fixtures/1.000/trunk/lib/DBIx/Class/Fixtures.pm	2008-02-04 17:08:33 UTC (rev 4021)
+++ DBIx-Class-Fixtures/1.000/trunk/lib/DBIx/Class/Fixtures.pm	2008-02-04 17:36:46 UTC (rev 4022)
@@ -83,6 +83,8 @@
 
 This will fetch artists with primary keys 1 and 3, the producer with primary key 5 and two of producer 5's artists where 'artists' is a has_many DBIx::Class rel from Producer to Artist.
 
+The top level attributes are as follows:
+
 =head2 sets
 
 Sets must be an array of hashes, as in the example given above. Each set defines a set of objects to be included in the fixtures. For details on valid set attributes see L</SET ATTRIBUTES> below.
@@ -139,6 +141,22 @@
 
 rules must be a hash keyed by class name.
 
+L</RULE ATTRIBUTES>
+
+=head2 datetime_relative
+
+Only available for MySQL and PostgreSQL at the moment, must be a value that DateTime::Format::* can parse. For example:
+
+    {
+        sets: [{
+            class: 'RecentItems',
+            ids: ['9']
+        }],
+        datetime_relative : "2007-10-30 00:00:00"
+    }
+
+This will work when dumping from a MySQL database and will cause any datetime fields (where datatype => 'datetime' in the column def of the schema class) to be dumped as a DateTime::Duration object relative to the date specified in the datetime_relative value. For example if the RecentItem object had a date field set to 2007-10-25, then when the fixture is imported the field will be set to 5 days in the past relative to the current time.
+
 =head2 might_have
 
 Specifies whether to automatically dump might_have relationships. Should be a hash with one attribute - fetch. Set fetch to 1 or 0.
@@ -243,6 +261,8 @@
 
 Set fetch to 1 if you want to fetch them, and quantity to either 'all' or an integer.
 
+Be careful here, dumping has_many rels can lead to a lot of data being dumped.
+
 =head2 might_have
 
 As with has_many but for might_have relationships. Quantity doesn't do anything in this case.
@@ -283,8 +303,8 @@
 
 =back
 
-Returns a new DBIx::Class::Fixture object. %attrs has only valid key at the
-moment - 'config_dir' which is required and much contain a valid path to
+Returns a new DBIx::Class::Fixture object. %attrs has only two valid keys at the
+moment - 'debug' which determines whether to be verbose and 'config_dir' which is required and much contain a valid path to
 the directory in which your .json configs reside.
 
   my $fixtures = DBIx::Class::Fixtures->new({ config_dir => '/home/me/app/fixture_configs' });
@@ -623,10 +643,10 @@
     connection_details => ['dbi:mysql:dbname=app_dev', 'me', 'password'] # database to clear, deploy and then populate
   });
 
-In this case the database app_dev will be cleared entirely of everything, then the DDL deployed to it, 
+In this case the database app_dev will be cleared of all tables, then the specified DDL deployed to it,
 then finally all fixtures found in /home/me/app/fixtures will be added to it. populate will generate
 its own DBIx::Class schema from the DDL rather than being passed one to use. This is better as
-custom insert methods etc are avoided which tend to get in the way. In some cases you might not
+custom insert methods are avoided which can to get in the way. In some cases you might not
 have a DDL, and so this method will eventually allow a $schema object to be passed instead.
 
 directory, dll and connection_details are all required attributes.