+
+1;
+
+__END__
+
+=encoding utf-8
+
+=head1 NAME
+
+rose_auto_create_model - mana Rose::DB::Object classes for Lx-Office
+
+=head1 SYNOPSIS
+
+ scripts/rose_create_model.pl --login login table1[=package1] [table2[=package2] ...]
+ scripts/rose_create_model.pl --login login [--all|-a] [--sugar|-s]
+
+ # updates all models
+ scripts/rose_create_model.pl --login login --all
+
+ # updates only customer table, login taken from config
+ scripts/rose_create_model.pl customer
+
+ # updates only parts table, package will be Part
+ scripts/rose_create_model.pl parts=Part
+
+ # try to update parts, but don't do it. tell what would happen in detail
+ scripts/rose_create_model.pl --no-commit --verbose parts
+
+=head1 DESCRIPTION
+
+Rose::DB::Object comes with a nice function named auto initialization with code
+generation. The documentation of Rose describes it like this:
+
+I<[...] auto-initializing metadata at runtime by querying the database has many
+caveats. An alternate approach is to query the database for metadata just once,
+and then generate the equivalent Perl code which can be pasted directly into
+the class definition in place of the call to auto_initialize.>
+
+I<Like the auto-initialization process itself, perl code generation has a
+convenient wrapper method as well as separate methods for the individual parts.
+All of the perl code generation methods begin with "perl_", and they support
+some rudimentary code formatting options to help the code conform to you
+preferred style. Examples can be found with the documentation for each perl_*
+method.>
+
+I<This hybrid approach to metadata population strikes a good balance between
+upfront effort and ongoing maintenance. Auto-generating the Perl code for the
+initial class definition saves a lot of tedious typing. From that point on,
+manually correcting and maintaining the definition is a small price to pay for
+the decreased start-up cost, the ability to use the class in the absence of a
+database connection, and the piece of mind that comes from knowing that your
+class is stable, and won't change behind your back in response to an "action at
+a distance" (i.e., a database schema update).>
+
+Unfortunately this reads easier than it is, since classes need to go into the
+right package and directory, certain stuff needs to be adjusted and table names
+need to be translated into their class names. This script will wrap all that
+behind a few simple options.
+
+In the most basic version, just give it a login and a table name, and it will
+load the schema information for this table and create the appropriate class
+files, or update them if already present.
+
+Each table has two associated files. A C<SL::DB::MetaSetup::*> class, which is
+a perl version of the schema definition, and a C<SL::DB::*> class file. The
+first one will be updated if the schema changes, the second one will only be
+created if it does not exist.
+
+=head1 OPTIONS
+
+=over 4
+
+=item C<--login, -l LOGIN>
+
+=item C<--user, -u LOGIN>
+
+Provide a login. If not present the login is loaded from the config key
+C<devel/login>. If that too is not found, an error is thrown.
+
+=item C<--all, -a>
+
+Process all tables from the database. Only those that are blacklistes in
+L<SL::DB::Helper::Mappings> are excluded.
+
+=item C<--sugar, -s>
+
+Process tables in sugar schema instead of standard schema. Rarely useful unless
+you debug schema awareness of the RDBO layer.
+
+=item C<--no-commit, -n>
+=item C<--dry-run>
+
+Do not write back generated files. This will do everything as usual but not
+actually modify any file.
+
+=item C<--diff>
+
+Displays diff for selected file, if file is present and newer file is
+different. Beware, does not imply C<--no-commit>.
+
+=item C<--help, -h>
+
+Print this help.
+
+=item C<--verbose, -v>
+
+Prints extra information, such as skipped files that were not changed and
+errors where the auto initialization failed.
+
+=back
+
+=head1 BUGS
+
+None yet.
+
+=head1 AUTHOR
+
+Sven Schöling E<lt>s.schoeling@linet-services.deE<gt>
+
+=cut