0.03003 fixes for external layered definitions while dumping
[dbsrgits/DBIx-Class-Schema-Loader.git] / lib / DBIx / Class / Schema / Loader.pm
index 39e9277..0a17552 100644 (file)
@@ -13,7 +13,7 @@ use Scalar::Util qw/ weaken /;
 # Always remember to do all digits for the version even if they're 0
 # i.e. first release of 0.XX *must* be 0.XX000. This avoids fBSD ports
 # brain damage and presumably various other packaging systems too
-our $VERSION = '0.03000';
+our $VERSION = '0.03003';
 
 __PACKAGE__->mk_classaccessor('dump_to_dir');
 __PACKAGE__->mk_classaccessor('loader');
@@ -49,7 +49,7 @@ L<DBIx::Class::Schema> by scanning database table definitions and
 setting up the columns and primary keys.
 
 DBIx::Class::Schema::Loader currently supports DBI for MySQL,
-Postgres, SQLite and DB2.
+PostgreSQL, SQLite and DB2.
 
 See L<DBIx::Class::Schema::Loader::DBI::Writing> for notes on writing
 your own vendor-specific subclass for an unsupported DBD driver.
@@ -121,7 +121,6 @@ sub _invoke_loader {
     $class->loader($impl->new(%{$self->_loader_args}));
     $class->loader->load;
 
-
     $self;
 }
 
@@ -229,14 +228,15 @@ sub import {
 This simple function allows one to create a Loader-based schema
 in-memory on the fly without any on-disk class files of any
 kind.  When used with the C<dump_directory> option, you can
-use this to generate a rought draft manual schema from a dsn
+use this to generate a rough draft manual schema from a dsn
 without the intermediate step of creating a physical Loader-based
 schema class.
 
 This function can be exported/imported by the normal means, as
 illustrated in these Examples:
 
-    # Simple example...
+    # Simple example, creates as a new class 'New::Schema::Name' in
+    #  memory in the running perl interpreter.
     use DBIx::Class::Schema::Loader qw/ make_schema_at /;
     make_schema_at(
         'New::Schema::Name',
@@ -245,7 +245,7 @@ illustrated in these Examples:
     );
 
     # Complex: dump loaded schema to disk, all from the commandline:
-    perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:./lib -e 'make_schema_at("New::Schema::Name", { relationships => 1 }, [ 'dbi:Pg:dbname="foo"','postgres' ])'
+    perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:./lib -e 'make_schema_at("New::Schema::Name", { relationships => 1 }, [ "dbi:Pg:dbname=foo","postgres" ])'
 
     # Same, but inside a script, and using a different way to specify the
     # dump directory:
@@ -269,6 +269,7 @@ sub make_schema_at {
         __PACKAGE__->loader_options($opts_dumped);
         __PACKAGE__->connection($cinfo_dumped);
     |;
+    croak "make_schema_at failed: $@" if $@;
 }
 
 =head1 EXAMPLE
@@ -302,7 +303,7 @@ will issue warnings about your usage of deprecated features/methods.
 
 This deprecated method is now roughly an alias for L</loader_options>.
 
-This method *will* dissappear in a future version.
+This method *will* disappear in a future version.
 
 For now, using this method will invoke the legacy behavior for
 backwards compatibility, and merely emit a warning about upgrading
@@ -322,8 +323,18 @@ See the source of this method for more details.
 
 sub load_from_connection {
     my ($self, %args) = @_;
+
+    my $cmds_ver = $Catalyst::Model::DBIC::Schema::VERSION;
+    if($cmds_ver) {
+        if($cmds_ver < 0.14) {
+            warn 'You should upgrade your installation of'
+               . ' Catalyst::Model::DBIC::Schema to 0.14 or higher, then:';
+        }
+        warn 'You should regenerate your Model files, which may eliminate'
+           . ' the following deprecation warning:';
+    }
     warn 'load_from_connection deprecated, please [re-]read the'
-      . ' [new] DBIx::Class::Schema::Loader documentation';
+       . ' [new] DBIx::Class::Schema::Loader documentation';
 
     # Support the old connect_info / dsn / etc args...
     $args{connect_info} = [
@@ -354,7 +365,7 @@ for doing so.
 
 If you're already using C<loader> in your code, make an effort
 to get rid of it.  If you think you've found a situation where it
-is neccesary, let me know and we'll see what we can do to remedy
+is necessary, let me know and we'll see what we can do to remedy
 that situation.
 
 In some future version, this accessor *will* disappear.  It was
@@ -368,7 +379,7 @@ user-land in the first place, all things considered.
 Currently the loader is limited to working within a single schema
 (using the database vendors' definition of "schema").  If you
 have a multi-schema database with inter-schema relationships (which
-is easy to do in Postgres or DB2 for instance), you only get to
+is easy to do in PostgreSQL or DB2 for instance), you only get to
 automatically load the tables of one schema, and any relationships
 to tables in other schemas will be silently ignored.