tag:blogger.com,1999:blog-37642571.post1358819079415280612..comments2024-03-20T02:30:44.457-07:00Comments on Thinking In Software: MySQL Java Driven Metadata changesNestor Urquizahttp://www.blogger.com/profile/12351754666722274569noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-37642571.post-6421336666839510112010-08-16T12:04:37.907-07:002010-08-16T12:04:37.907-07:00To create the DB from scratch is as easy as runnin...To create the DB from scratch is as easy as running the latest from SVN $DB.sql and data.sql<br />To get any release from scratch it is as easy as running $DB.sql and data.sql from a tag. <br />To migrate to a given release number from an existing release is as easy as running all migration_metadata.sql and migration_data.sql from tags starting at current release version + 1 <br />To rollback to any previous release number it is as easy as running rollback.sql starting at the current release tag all the way down to target release – 1. Of course some data will be lost.Nestor Urquizahttps://www.blogger.com/profile/12351754666722274569noreply@blogger.comtag:blogger.com,1999:blog-37642571.post-57220033998288046942010-08-15T11:41:31.989-07:002010-08-15T11:41:31.989-07:00I guess the $DB.sql has all previous release's...I guess the $DB.sql has all previous release's schema changes? Otherwise automation must be in place to run all previous schema changes starting from the base. Another approach is to have one folder with the base file and each schema file with a convention of something like ${id}.${majorReleaseNumber}.${minorReleaseNumber}.${pointReleaseNumber}.sql. Then all of the files can be run in order.Anonymoushttps://www.blogger.com/profile/03501157981623900884noreply@blogger.com