Hi Mike,
It will be interesting to see what the Servoy team comes up with in this respect. Meanwhile I have developed my own method of version control, borrowing from Ruby-on-Rails.
If you are using any database supported by Rails, mySQL, PostgreSQL etc you can point an empty rails project at your Servoy project and run Migrations on your database.
On Mac OS X 10.5 it is pre-installed:
- Code: Select all
rails myServoyProject
Go to 'db/database.yml' and edit the database connections. Make sure you point the 'test' connection to an empty database as the test database gets deleted and recreated if you ever were to run a test.
Then
- Code: Select all
script/generate migration OrderAdditions
This creates a file called 001_order_additions
Then you can write Ruby code to modify the database
- Code: Select all
class OrderAdditions < ActiveRecord::Migration
def self.up
add_column :orders, :submitted, :integer
add_column :orders, :processed, :integer
remove_column :orders, :order_sid
end
def self.down
remove_column :orders, :submitted
remove_column :orders, :processed
add_column :orders, :order_sid, :string,:default => "", :null => false
end
end
self.up/self.down means you can step forward or backwards between versions. This code is database neutral unless you execute SQL directly using the 'execute()' command. You can check the whole project directory into Subversion or some other source control.
Then you run
- Code: Select all
rake db:migrate
which will modify your development database, or,
- Code: Select all
rake db:migrate RAILS_ENV=production
to modify the production server.
You do need to restart Servoy after running migrations.
I'm currently using this technique to clean up a large Servoy system which has its roots back in Servoy version 1.2. I have about 15 migration files with maybe 1,000 changes. When ready to deploy, I only need to run
- Code: Select all
rake db:migrate RAILS_ENV=production
once. And the structure of my production database with my latest data will be up-to-date.
Rails creates a single table
- Code: Select all
CREATE TABLE schema_info
(
"version" integer
)
keeping track of the current version of your database.
When writing migrations, you can manipulate the 'version' number you can run the same migration again if it was to fail.
Anyway,
let's see what the Servoy team comes up with ;-)