[Jifty-commit] r2851 - in jifty/branches/template-declare: . lib/Jifty/Manual lib/Jifty/Script

jifty-commit at lists.jifty.org jifty-commit at lists.jifty.org
Mon Feb 26 20:44:36 EST 2007


Author: jesse
Date: Mon Feb 26 20:44:35 2007
New Revision: 2851

Added:
   jifty/branches/template-declare/lib/Jifty/Manual/Deploying.pod
Modified:
   jifty/branches/template-declare/   (props changed)
   jifty/branches/template-declare/lib/Jifty/Manual/Glossary.pod
   jifty/branches/template-declare/lib/Jifty/Manual/Upgrading.pod
   jifty/branches/template-declare/lib/Jifty/Script/Schema.pm
   jifty/branches/template-declare/lib/Jifty/Upgrade.pm

Log:
 r48565 at pinglin (orig r2844):  sterling | 2007-02-26 11:34:13 -0500
 added boundary match in rename to prevent similar column names from being hit by accident
 r48567 at pinglin (orig r2846):  sterling | 2007-02-26 13:24:12 -0500
 updated the upgrading manual and added a few extra glossary items
 r48568 at pinglin (orig r2847):  sterling | 2007-02-26 15:59:17 -0500
 added a Deploying page to the manual based on the process I have found successful
 r48571 at pinglin (orig r2849):  jesse | 2007-02-26 20:13:19 -0500
  r48514 at pinglin:  jesse | 2007-02-25 15:20:15 -0500
  * Plugin templates should override the core, but not application templates
  r48515 at pinglin:  jesse | 2007-02-25 16:14:59 -0500
  * Since we use the schema tool to manage jifty's database, it's important that it be able to be called from running code (including a DESTROY block). As it was, we were initializing (reinitializing) Jifty from within the DESTROY. That doesn't work so well.
  
  r48516 at pinglin:  jesse | 2007-02-25 16:17:30 -0500
  * Better test for "jifty already initted"
  r48564 at pinglin:  jesse | 2007-02-26 20:07:19 -0500
  * Fix adding columns during an upgrade.
 
 r48573 at pinglin (orig r2850):  jesse | 2007-02-26 20:42:13 -0500
  r48572 at pinglin:  jesse | 2007-02-26 20:41:54 -0500
  * Typo fixes to the deploymet guide
 


Added: jifty/branches/template-declare/lib/Jifty/Manual/Deploying.pod
==============================================================================
--- (empty file)
+++ jifty/branches/template-declare/lib/Jifty/Manual/Deploying.pod	Mon Feb 26 20:44:35 2007
@@ -0,0 +1,398 @@
+=head1 NAME
+
+Jifty::Manual::Deploying - Deploying your application for production use
+
+=head1 DESCRIPTION
+
+This document is intended to answer two questions:
+
+=over
+
+=item *
+
+Now that you've developed your Jifty application, how do you deploy it on the production server? 
+
+=item *
+
+Once deployed, what's the process for performing upgrades to the production server?
+
+=back
+
+Developers and administrators may wish to use this document as a checklist to make sure they hit everything when deploying. This document should be updated according to the best practices of Jifty deployment to aid this end.
+
+=head1 HOW TO
+
+=head2 Installing on a Production Server
+
+Once you've finished developing your Jifty application and you want to deploy it for use on a production server you'll need to follow these steps:
+
+=over
+
+=item 1.
+
+Install Jifty on your production server.
+
+=item 2.
+
+Copy your application onto the production server.
+
+=item 3.
+
+Adjust the configuration to suit your production environment.
+
+=item 4.
+
+Deploy your production database.
+
+=item 5.
+
+Configure your web server.
+
+=item 6.
+
+Start using your production service.
+
+=back
+
+=head3 Install Jifty
+
+Jifty installation proceeds just as it did on your development machine (or machines). If you installed from CPAN, you may do the same for your production server. 
+
+  perl -MCPAN -e 'install Jifty'
+
+or download Jifty and run:
+
+  tar zxf Jifty-VERSION.tar.gz
+  cd Jifty-VERSION
+  perl Makefile.PL
+  make
+  make test
+  sudo make install
+
+You may also have installed it via the package manager available for your Linux distribution.
+
+Finally, you may want to use bleeding-edge features available only in the Jifty Subversion repository. This has a slightly higher risk, but this is what the Best Practical team does for their Jifty applications. When doing this, you will probably want to be sure to check out the exact same version as you are using on your development machines.
+
+Be sure to run the tests when installing Jifty to make sure there aren't any problems on your production server that you need to fix before deploying your application.
+
+=head3 Copy the Application
+
+After you've gotten Jifty deployed, you need to copy your application onto the server. This can be done in whatever way suits your project. You can run your Jifty application straight out of the development directory just as you have on testing. Just place the directory into an appropriate location on your server.
+
+It may be advisable to consider using a version control system, such as SVK or Subversion, to aid you in this process. For example, with either SVK or Subversion, any production customizations can be handled as branches of your application to help you keep those changes sorted out clearly. This can also help you if you make any tweaks to the code on the production server that need to be put back into your development.
+
+Here is an example of how to create the branch in Subversion or. This example is built upon in the L<Upgrading the Production Server> section below.
+
+All these commands are assumed to be running on the production server in this example, but you could do much of these from anywhere.
+
+  svn mkdir http://svn.example.com/myapp/branches
+  svn copy http://svn.example.com/myapp/trunk \
+           http://svn.example.com/myapp/branches/production
+  svn checkout http://svn.example.com/myapp/branches/production \
+               myapp
+  cd myapp
+
+Make sure to remember (possibly by recording it in the log messages) which revision your trunk was at when you ran the copy command. This will be important later. If you're using SVK rather than Subversion, you don't have to worry about this.
+
+In SVK:
+
+  svk mkdir //myapp/branches
+  svk copy //myapp/trunk //myapp/branches/production
+  svk checkout //myapp/branches/production myapp
+  cd myapp
+
+You will now have a copy of the latest version of your project in the directory named F<myapp>. You can then make any of the modifications you need to to get your application configured for the production environment (read the following sections for details).
+
+When you're finished, commit those changes to the branch:
+
+  svn commit
+
+or in SVK:
+
+  svk commit
+
+All of these changes will be made only to the production branch. In the upgrade section, it will be clearer how this will help you.
+
+=head3 Tweak the Configuration
+
+After you've copied your application onto the server, change into that directory and make any changes to your configuration required for production.
+
+Here are some things you'll want to consider changing:
+
+=over
+
+=item AdminMode
+
+While developing, you'll probably want to try running your application with this turned off. This turns on the administrative functions for managing models, data, and actions.
+
+Set this to 0 to turn it off.
+
+=item Database
+
+These settings will be covered in more detail in L</Deploy the Database>.
+
+=item DevelMode
+
+This turns off certain checks that slow down a production system but are vital to fast development. For example, with ever request to a server with C<DevelMode> turned on, the server checks to see if any of the library or template files have changed and reloads them, if this is turned on.
+
+By switching this setting off, you also enable extra caching and speed-up features including the use of L<CSS::Squish>, which helps your application load CSS files more quickly.
+
+=item LogConfig
+
+You may wish to add this option to specify a custom logger configuration. See L<Jifty::Logger>.
+
+=item LogLevel
+
+Depending on your environment, you may want to adjust the default log level or you may want to customize the log configuration by introducing an F<etc/log4perl.conf> configuration file.
+
+You can set the LogLevel to: DEBUG, INFO, WARN, ERROR, or FATAL to specify the level. If you want a custom log configuration for your server (allowing you to have per-module log settings among other features), you need to set L</LogConfig> and possibly L</LogReload>. See L<Jifty::Logger>
+
+=item LogReload
+
+This allows you specify a custom reload period for your log configuration, if you use L</LogConfig>. See L<Jifty::Logger>.
+
+=item Mailer
+
+In some cases you will want to adjust the mailer configuration used by Jifty. The mail configuration is used whenever L<Jifty::Notification> messages are sent, which may or may not be used by your application.
+
+If you change the C<Mailer> setting, be sure to also change C<MailerArgs> to match.
+
+See L<Jifty::Notification> and L<Email::Send>.
+
+=item MailerArgs
+
+You may want to adjust the configuration of the mailer you are using. See L<Jifty::Notification> and L<Email::Send>.
+
+=item Plugins
+
+You may want to disable plugins you've been using in your development that you don't ened in production. In general, if these plugins are well-behaved this isn't necessary, but you can provide yourself with extra insurance in case they are not.
+
+You can disable them without removing them from the file by commenting them out using the Perl-style "#" comment mark.
+
+=item Web
+
+=over
+
+=item BaseURL
+
+You will want to change the C<BaseURL> setting under C<Web> to make sure it shows the name of your production server's base URL.
+
+=item ServeStaticFiles
+
+If you want to improve the performance of your server, you may want your main web server to serve static files rather than having Jifty do it. You will need to manually flatten the static file structure yourself for this to work, but it can be done.
+
+=back
+
+=item etc.
+
+Your application configuration may have additional changes that need to be made for your application to operate properly in a production environment.
+
+Make sure to check over all the settings to make sure they will work in your produciton environment to save yourself headaches later.
+
+=back
+
+=head3 Deploy the Database
+
+If you've been developing your server using the default SQLite configuration, you will likely want to change this for your production server. SQLite might work for production environment, but chances are it will not.
+
+For your production system, you will probably want to modify the C<Driver> to suit your production environment. For example, if you were going to change to use a MySQL server, you might change your C<Database> configuration in F<etc/config.yml> to something like this:
+
+  Database:
+    Database: myapp
+    Driver: mysql
+    Host: mysql.example.com
+    Password: 'secret'
+    RecordBaseClass: Jifty::DBI::Record::Cachable
+    User: myapp_user
+    Version: 0.0.1
+
+In this example, the server is running the MySQL driver, connecting to the host at "mysql.example.com" with the username "myapp_user" and password "secret".
+
+You will need to create the database and grant access to the users according to your RDBMS administrator documentation. In MySQL, this could be done to match the example above by running these commands:
+
+  mysqladmin -uadmin -psecret create myapp
+  mysql -uadmin -psecret -e "grant all on myapp.\* to myapp_user'@'myapp.example.com identified by 'secret'"
+
+Please refer to your RDBMS documentation for full details on how to configure your database.
+
+=head3 Configure the Web Server
+
+There are two primary ways to configure your web server. You can use FastCGI or you can use a proxy to the Jifty simple server. You will most likely want to do the former, but the configuration for the latter is presented for completeness.
+
+=head4 Configuring FastCGI
+
+Several configurations are explained by the L<Jifty::Script::FastCGI/fastcgi> script that comes with Jifty. It is recommended that you take one of those and modify the configuration to suit your needs.
+
+It may take a few tries to get the configuration exactly right. Be sure to check the server logs for your web server when looking for problems.
+
+=head4 Configuring a Proxy
+
+You can use a proxy with the built-in server. This can be done with the following configuration in Apache:
+
+  <Location />
+  ProxyPass        / http://localhost:8888/
+  ProxyPassReverse / http://localhost:8888/
+  </Location>
+
+Place that declaration in your main configuration or virtual host configuration file and then whenever you run:
+
+  bin/jifty server
+
+Apache will proxy your server on port 80 for you. This may not work exactly as expected because the built-in server is intended for testing, not for a production environment. As such, it is not well-tested as a production server.
+
+=head3 All Systems Go
+
+Once you have done all of the above, your application should be ready to use at the production address you have configured.
+
+=head2 Updating the Production Server
+
+After you've made some collection of updates to your Jifty application, you'll then need to install those changes onto your server and prepr your application to use the changes.
+
+This documentation assumes a "cold" upgrade with the application offline during the duration of the process. A future version of this document might also include instructions for performing a "hot" upgrade without taking the server offline.
+
+You can do  his with the following steps:
+
+=over
+
+=item 1.
+
+Shutdown the application.
+
+=item 2.
+
+Update the Jifty installation.
+
+=item 3.
+
+Update your Jifty application.
+
+=item 4.
+
+Merge in configuration changes.
+
+=item 5.
+
+Clean up any temporary and cached files.
+
+=item 6.
+
+Upgrade your database.
+
+=item 7.
+
+Start using the updated application.
+
+=back
+
+=head3 Shutdown the Application
+
+This process cannot be performed on a live server. If it is, bad things may happen. You may choose to shutdown the application in one of two ways: turn off your web server or reconfigure your web server into an offline mode.
+
+Remember, shutdown all Jifty application processes before continuing, or bad things may happen!
+
+=head4 Shutting Down the Server
+
+This will involve a two step process. First, you will want to shutodwn your web server. The second is to shutdown the Jifty server. If you are using the built-in Jifty server, you may do this by running:
+
+  bin/jifty server --stop
+
+If you are using FastCGI, you will need to locate your server's process IDs and then kill all the processes. If this is the only FastCGI and Perl script running on your system, you may be able to just run:
+
+  killall perl
+
+However, that might stop too many processes in many environments, so you'll just have to find the processes and clean them up as suits your server.
+
+=head4 Offline Mode
+
+If you want to provide you site visitors with some feedback letting them know that the web site is down, you might want to provide an alternative configuration for your application. You still need to stop all your Jifty application processes when you engage the offline configuration.
+
+For example, you could have the following configuration on an Apache server to run an offline mode:
+
+  <Location />
+  RewriteEngine on
+  RewriteRule ^.*$ /offline.html
+  </Location>
+
+Then create a file named "offline.html" in your server root containing the message you wish to give your visitors.
+
+You can make this configuration change and then restart your web server to give it effect. Then, stop all the Jifty application processes.
+
+=head3 Update Jifty
+
+This is exactly the same as L</Install Jifty> above. Again, you'll probably want to install the same version as you are using to developing with. If you have not made any changes to the Jifty version you are using, you may skip this step.
+
+=head3 Update the Application
+
+This is again similar to what you've done above. You just need to update all the files that have changed. However, you should be careful not to clobber any configuration changes that you need to remember. 
+
+If you've used the suggestion of using a branch described above, you can automatically update your production server to use the latest code without risk of clobbering your changes on the production server.
+
+In Subversion, you will first need to recall the revision of either the initial copy or of the last merge you performed. If you stored this information in the log message, you can retrieve it by running:
+
+  svn log http://svn.example.com/myapp/branches/production
+
+When you have the revision number, you can then merge in all the latest changes in your production server copy. Here, I assume that the revision number is "1234".
+
+  cd myapp
+  svn merge -r 1234:HEAD http://svn.example.com/myapp/trunk .
+
+If you're using SVK, you can just run the following:
+
+  cd myapp
+  svk smerge //myapp/trunk .
+
+SVK automatically remembers the revision number for you so you don't have to worry about it.
+
+Next, watch for any conflicts that might have occurred and be sure to correct them. Check over all the changed files and make sure they look alright and you should also run your tests again to be sure everything is working. Once you're sure everything is correct, you can accept the changes with:
+
+  svn commit
+
+or:
+
+  svk commit
+
+Your code should now be ready. 
+
+=head3 Configuration Changes
+
+Again, you need to look for any configuration updates that need to adjusted. This is no different from the process during the initial installation.
+
+=head3 Clear Temporary/Cached Files
+
+This step is important to prevent strange issues from occuring. You remove all files from the following directories:
+
+=over
+
+=item *
+
+F<var/mason/cache>
+
+=item *
+
+F<var/mason/obj>
+
+=back
+
+You can run the following command (B<BE CAREFUL TO TYPE THIS CORRECTLY OR PAY THE CONSEQUENCES>):
+
+  rm -rf var/mason/{cache,obj}/*
+
+This means that your application will have to rebuild these cached files, which will slow your application down slightly at first. 
+
+However, if these files are left in place, the Mason server may continue using cached versions of files that don't match your latest updates. This will lead to very strange problems.
+
+=head3 Upgrade the Database
+
+If you've made any changes to the database schema or to the structure of your data that requires an upgrade, you will need to run:
+
+  bin/jifty schema --setup
+
+See L<Jifty::Manual::Upgrading>.
+
+=head3 All Systems Go
+
+Now that all these changes have been made, you are ready to start your web server or reconfigure your web server for production mode and restart.
+
+=head1 SEE ALSO
+
+L<Jifty::Manual::Tutorial>, L<Jifty::Manual::Upgrading>

Modified: jifty/branches/template-declare/lib/Jifty/Manual/Glossary.pod
==============================================================================
--- jifty/branches/template-declare/lib/Jifty/Manual/Glossary.pod	(original)
+++ jifty/branches/template-declare/lib/Jifty/Manual/Glossary.pod	Mon Feb 26 20:44:35 2007
@@ -1,6 +1,6 @@
 =head1 NAME
 
-Jifty::Manual::Glossary
+Jifty::Manual::Glossary - The Jifty dictionary
 
 =head1 GLOSSARY
 
@@ -42,6 +42,10 @@
 canonicalizer could translate a user-typed date into a date object or a
 SQL-formatted date string.  See L<Jifty::Action>.
 
+=item collection
+
+A B</collection> is a class representing all or a subset of the records stored in the database regarding a particular L</model>. See L<Jifty::Collection>.
+
 =item constructor
 
 A property of a L</parameter>; the action B<must> have an argument value for
@@ -60,6 +64,10 @@
 so they are often useful to keep track of tangents that the user went on.  See
 L<Jifty::Continuation>.
 
+=item database version
+
+The B<database version> is the L</schema version> last installed or updated in the application's database. In general, the database version will always match the schema version. The exception is when Jifty is updated to a new schema version, your application updates to a new schema version, or a plugin updates to a new schema version. When this happens, you must L</update> your database so that the database versions and schema versions match before running your application.
+
 =item form field
 
 A widget which the browser renders.  These are generally useful to ask the user
@@ -88,6 +96,10 @@
 A property of a L</parameter>; the user must enter a value for the action to
 validate.  This is the simplest level of L<validation|/validate>.
 
+=item model
+
+Jifty uses L<Jifty::DBI> to store its data (though might use other storage tools at some later time). The B<model> defines the L</schema> and provides a package for creating, reading, updating, and deleting records stored in the database. The model is generally a subclass of L<Jifty::Record>. Access multiple items from a model is performed through a L</collection>.
+
 =item moniker
 
 Every instance of a L<Jifty::Action> has a B<moniker>.  A moniker is
@@ -127,6 +139,34 @@
 success or failure, and further detail about why or how.  It can also contain
 arbitrary "content".  See L<Jifty::Result>.
 
+=item schema
+
+The B<schema> for a L</model> represents the structure of the data stored in an individual item in that model's L</collection>. See L<Jifty::DBI::Schema>.
+
+=item schema version
+
+The B<schema version> is a number in L<version> object used to determine which L</database version> your application code is expecting to use. There are three places where the schema version is important: 
+
+=over
+
+=item 1.
+
+I<Jifty application version>. The Jifty application stores some details in the database.
+
+=item 2.
+
+I<Your database version>. Your application keeps a database version recorded in the configuration. See L<Jifty::Config>.
+
+=item 3.
+
+I<Plugin versions>. Each plugin has a version associated with it affecting whatever C</model>s it uses.
+
+=back 
+
+If any of these versions differs from their respective L</database version>s, then you need to run the L<Jifty::Script::Schema|schema setup script> to L</upgrade> to the latest schema version. 
+
+Contrast with L</database version>.
+
 =item sticky
 
 A property of L</form field>s.  If a field is "sticky," values that the user
@@ -134,6 +174,10 @@
 user type them again.  Most L</action>s have form fields which are sticky on
 failure, so the user can update the information and try again.
 
+=item upgrade
+
+Generally, your Jifty application will change over time. Most of these changes will be simple changes to behavior or appearance. When changes are made to the L</schema> structure of your database, you may need to perform an B<upgrade>. An B<upgrade> is the process by which you rename columns, initialize data, or otherwise update information that needs to be updated when a change to the database needs to be made. See L<Jifty::Upgrade>, L<Jifty::Manual::Upgrading>, and L<Jifty::Script::Schema>.
+
 =item validate
 
 To check that the provided value of an L</argument> is a possible value for it

Modified: jifty/branches/template-declare/lib/Jifty/Manual/Upgrading.pod
==============================================================================
--- jifty/branches/template-declare/lib/Jifty/Manual/Upgrading.pod	(original)
+++ jifty/branches/template-declare/lib/Jifty/Manual/Upgrading.pod	Mon Feb 26 20:44:35 2007
@@ -1,6 +1,6 @@
 =head1 NAME
 
-Jifty::Manual::Upgrading
+Jifty::Manual::Upgrading - How-to change your application database over time
 
 =head2 DESCRIPTION
 
@@ -10,15 +10,62 @@
 almost automatically.  If more extensive changes are required you need
 to write some code to tell Jifty what to do.
 
+=head1 TERMINOLOGY
+
+Be sure you know the following terms before reading this document:
+
+=over
+
+=item *
+
+L<Jifty::Manual::Glossary/schema>
+
+=item *
+
+L<Jifty::Manual::Glossary/schema version>
+
+=item *
+
+L<Jifty::Manual::Glossary/database version>
+
+=back
+
 =head1 HOW TO
 
-=head2 New models and columns
+=head2 General Instructions
+
+For all of these actions, the the database version stored in your Jifty configuration is significant. See the value stored in F<etc/config.yml> at:
+
+  framework:
+    Database:
+      Version: 0.0.1
+
+Make all your code changes using the version number I<you are going to use>. Once you have finished updating your code and are ready to test, bump the version stored in F<etc/config.yml> to match the new version you are going to use.
+
+If you are writing tests as you go (shame on you if you aren't!), you should be able to run:
+
+  perl Makefile.PL
+  make
+  make test
+
+to test the latest version and check for problems.
+
+Once you are sure you've worked out the kinds, you may perform the actual upgrade by running:
+
+  bin/jifty schema --setup
+
+This will take care of the work of adding any new columns and models, dropping old columns, and running any upgrade scripts you have scheduled.
+
+=head2 Basic column and model operations
 
 =head3 Adding a new model
 
-When adding a new model to your application you need to tell Jifty
-at which version of your application the model was created.  To do
-this add a since sub to your new model class.
+Create your model just as you normally would:
+
+  bin/jifty model --name MyModel
+
+Then, you need to tell Jifty at which version of your application the model was
+created.  To do this add a since sub to your new model class.
 
  sub since { 0.0.5 }
 
@@ -33,7 +80,24 @@
     refers_to Wifty::Model::User, 
     since '0.0.20';
 
-=head2 data migration and schema changes
+=head3 Dropping a column from a model
+
+B<CAUTION:> Be aware that all the data that was stored in this column will be destroyed at upgrade if you follow this procedure.
+
+If you no longer need a particular column in your model, you can have it dropped by setting the C<till> property on your column definition.
+
+ column extra_info
+     type is 'text',
+     label is 'Extra info',
+     till '0.0.13';
+
+The version you use for C<till> is the version the drop is effective. In the example above, the C<extra_info> column will be available in version 0.0.12, but not in version 0.0.13.
+
+This column will be dropped from the schema at the next upgrade, I<which will destroy all data stored in that column.>
+
+=head3 TODO Dropping a model
+
+=head2 Data migration and schema changes
 
 If a file called F<Upgrade.pm> exists in your application it will be
 run by C<jifty schema --setup>.
@@ -57,16 +121,58 @@
 
 =head3 Renaming a column
 
-To rename a column, simply call C<rename> inside your C<since> code block:
+To rename a column, you need to make sure that your schema and upgrade script both cooperate in the process. Your schema will record changes to your model API and the upgrade script will tell Jifty about the rename.
+
+The old column name needs to marked with C<till> to notify Jifty that the column name no longer exists. The new column name needs to marked with C<since> to notify Jifty that a column by the new name exists. 
 
-    use MyApp::Model::User;
+Here we are renaming C<zip> to C<postcode>:
 
-    since '0.6.1' => sub {
-        rename(
-            table   => 'MyApp::Model::User', 
-            column  => 'zip', 
-            to      => 'postcode'
-        );
-    };
+  column zip =>
+      type is 'text',
+      label is 'ZIP code',
+      till '0.6.1';
+
+  column postcode =>
+      type is 'text',
+      label is 'Postal code',
+      since '0.6.1';
+
+Notice that both C<since> and C<till> have the same version number set. This is the version number the change will take place.
+
+Before you upgrade, though, you must tell Jifty that a rename is happening here, which is done in your upgrade script:
+
+ use MyApp::Upgrade;
+
+ use base qw(Jifty::Upgrade);
+ use Jifty::Upgrade qw( since rename );
+
+ since '0.6.1' => sub {
+     rename(
+         table   => 'MyApp::Model::User', 
+         column  => 'zip', 
+         to      => 'postcode'
+     );
+ };
 
 =head3 Migrating data
+
+You can perform any action you want inside the C<since> blocks of your upgrade script. In the case of data migration, you might want to convert your data from one form to another.
+
+For example, let's say our users always gave us C<first_name> and C<last_name> before, but we've added a new column C<display_name> which will normally contain their name in "last, first" format, but could be customized per-account. We want to go ahead and initialize this new column during the upgrade. In your upgrade script, you could add:
+
+  since '0.2.4' => sub {
+      my $users = MyApp::Model::UserCollection->new;
+      $users->unlimit;
+
+      while (my $user = $users->next) {
+          $user->set_display_name(
+              join(', ', $user->last_name, $user->first_name)
+          );
+      }
+  };
+
+=head1 SEE ALSO
+
+L<Jifty::Upgrade>, L<Jifty::Script::Schema>, L<Jifty::Manual::Models>, L<Jifty::Manual::Tutorial>, L<Jifty::Manual::Glossary>
+
+=cut

Modified: jifty/branches/template-declare/lib/Jifty/Script/Schema.pm
==============================================================================
--- jifty/branches/template-declare/lib/Jifty/Script/Schema.pm	(original)
+++ jifty/branches/template-declare/lib/Jifty/Script/Schema.pm	Mon Feb 26 20:44:35 2007
@@ -375,7 +375,7 @@
                         my $renamed = $upgradeclass->just_renamed || {};
 
                         # skip it if this was dropped by a rename
-                        $model->drop_column_sql($col->name)
+                        _exec_sql($model->drop_column_sql($col->name))
                             unless defined $renamed
                                 ->{ $model->table }
                                 ->{'drop'}
@@ -384,12 +384,12 @@
                 }
 
                 # If they're new, add them
-                if ($model->can( 'since' ) and defined $col->since and $appv >= $col->since and $col->since >$dbv ) {
+                if ($col->can( 'since' ) and defined $col->since and $appv >= $col->since and $col->since >$dbv ) {
                     unshift @{ $UPGRADES{ $col->since } }, sub {
                         my $renamed = $upgradeclass->just_renamed || {};
 
                         # skip it if this was added by a rename
-                        $model->add_column_sql($col->name)
+                        _exec_sql($model->add_column_sql($col->name))
                             unless defined $renamed
                                 ->{ $model->table }
                                 ->{'add'}
@@ -427,9 +427,7 @@
                 $log->info("Running upgrade script");
                 $thing->();
             } else {
-                my $ret = Jifty->handle->simple_query($thing);
-                $ret
-                    or die "error updating a table: " . $ret->error_message;
+                _exec_sql($thing);
             }
         }
     }
@@ -547,6 +545,13 @@
     }
 }
 
+sub _exec_sql {
+    my $sql = shift;
+    my $ret = Jifty->handle->simple_query($sql);
+    $ret or die "error updating a table: " . $ret->error_message;
+}
+
+
 1;
 
 __DATA__

Modified: jifty/branches/template-declare/lib/Jifty/Upgrade.pm
==============================================================================
--- jifty/branches/template-declare/lib/Jifty/Upgrade.pm	(original)
+++ jifty/branches/template-declare/lib/Jifty/Upgrade.pm	Mon Feb 26 20:44:35 2007
@@ -102,7 +102,7 @@
             my @column_info = ( split /,/, $schema );
             my @column_names = map { /^\s*(\S+)/ ? $1 : () } @column_info;
 
-            s/^(\s*)\Q$args{column}\E/$1$args{to}/i for @column_info;
+            s/^(\s*)\b\Q$args{column}\E\b/$1$args{to}/i for @column_info;
 
             my $new_schema = $new_create_clause . join( ',', @column_info );
             my $copy_columns = join(


More information about the Jifty-commit mailing list