Upgrading to Version 1.5.3 from 1.0

It does.

But the one thing I am not sure if this will work for you, as it means adding a few servers or Virtual Machines or what ever into the mix, depending on your testing and staging and whether you do this or not.

But I am assuming you have a server that you use, that would be testing the changes to be deployed. Once you’re happy here, you may then setup a staging server that would be the exact copy of what is to be deployed. I use this as an example, your process might not allow for this but I am giving you an option that may work if tweaked a bit to suit your process.

When you use the testing server, to get the updates and other things applied. You could then use a tool like red-gate SQL Tools that can be scripted via ant or other means, that can compare the testing database with the staging database and create the scripts that will give you the SQL to migrate the changes.

Note that this only works if you already have this sort of process, and most who deploy like you are, have something similar. So without knowing your situation, and whether this option may help you. Red-Gate are very good when it comes to things like this, and there are many options that could work for your situation as well.

I wrote some posts showing how you can automate and even version your DB changes with these tools, if that helps let me know.

http://www.andyscott.id.au/blog/Version-control-your-SQL-Server-with-RedGate-SQL-Tools

http://www.andyscott.id.au/blog/version-control-database-schema-part-ii

http://www.andyscott.id.au/blog/version-control-database-schema-the-sql-compare-way-from-redgate

Thank you Andrew,

I have to checkout Red Gate for sure, looks great. And your blog post are great too, like always.

So, it would be great to get the database update from Luis, whoch saves me some reverse engineering.

I’m still looking for an easy solution to do the updates with the help of our Software Management System.

I know now, that the update of the database will be done with the internal update mechanism of ContentBox.
I played around with two databases havieng an old and new version of ContentBox. Reverse-Engineering is not the solution, needs to much time.

Is it possible that an update can include a SQL file, which i can run with my toys? I’m not familiary with ORM, but i think at the end of day SQL-statements will be executed anyway to update the database, right?

@Luis: I cant’ see any hint or documentation in the zipped update files regarding the database.

Martin,

Unfortunately we do not use something like migrations. We rely on hibernate updating the database from our object model. We do not remove or alter tables as that is too messy for users, so we place instructions if they will need to remove things.

At this point in time, unless I can get a migrations system ready I have no way of providing SQL, unless somebody knows of a tool that can diff two databases and spit a sql file.

Not to mention one that is compatible with all the databases for ORM.

ContentBox already stores the version it’s currently on. On startup, what if it scanned the updates folder and if it found an update which was a later version than the current install, it would process it and then update its internal version? This would allow someone to deploy the update via some sort of source control push to an install, and then the installation would automatically pick it up and process it.

This would also be a good time for us to finally make updates cumulative. If each update stores the previous version, the update mechanism can ensure it only installs that update if the current install is the previous version. If not, if means you skipped a version somewhere and it could minimally throw an error, or ideally automatically download the previous version. Rinse and repeat until you reach an update whose previous version is the current version. Now, you start installing them in reverse order until you are current.

Of course, this assumes that all previous versions are available online for download and the download URL is guessable by convention given the version number, or each update could simply also include the URL to the previous version.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

If the source control was Subversion, there is another answer. not sure how to do this with GIt though.

But here is what would happen.

ContentBox goes and checks to see if there is an update, passing along the current version number. The update server then gets a patch from the source control that is build up on the fly, that holds every update from that version.

So if I am running version 1.1 when I update, I am told 1.6 is available and whether I wish to update.

The update I get is a single file that contains all the changed files since V1.1 to V1.6 and updates.

Every source or revision control system has the ability to create a diff from any revision, why not leverage that.

That is what I leverage already. And since 1.5.0 they are cumulative. The git script I have produces all the necessary changes. Then the updater cfc does the programmatic updates.

However, eventually the updates get huge. So I will only do cumulative for the same minor version not majors.

Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions

ContentBox needs more than just a diff of the files between revisions A and B. That’s why Luis packages the updates with a CFC file that has to be executed that takes care of copying files and executing ORM updates.

We still have to address Martin’s scenario too in which his production server does not have the typical update process manually run. He runs that on dev/QA, commits the patch(s) and then pushes that commit to a production server which then needs to figure out the fact that there are new patches present and process them. it’s not enough just to copy the files. This means the special patch CFC Luis creates needs to be executed again on that production server so the ORM queries and such can be run.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Interesting. I didn’t know you had done that. How do you do cumualitve udpates to the DB without creating duplicate records?

I like my approach better as each patch is no larger than it needs to be and it can go back indefinitely.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Well it verifies the db and data integrity. Only does updates if necessary.

However i do prefer your approach. This was the easy fix :slight_smile:

Luis Majano
CEO
Ortus Solutions, Corp
Toll Free/Fax: 1-888-557-8057
Direct: 909-248-3408
www.ortussolutions.com
Twitter: @lmajano, @ortussolutions

Brad, please read what I said. I know how the DIFF works, and why I clearly stated the files that have changed. Seriously, I thought I made that clear.

I did, and mentioned it in a ContentBox session to you Brad, where you and I went looking for it and couldn’t find it in the source.

Problem with that is how to you handle rollbacks if something goes wrong?

Honestly I’m not very clear at all on how you envisioned it working. All I know is it would involve a diff, but you didn’t address how DB updates would get executed or how the Update.cfc would be built, or if there would be multiple Update.cfcs and if so, how they would be executed in order. I can imagine ways it might work, but it wasn’t clear in your post how you saw it working.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Yes, I do recall that conversation. Luis, can you tell us when you changed patches to be cumulative? I can’t find any commits on Github with that word, and the ticket for that feature is still open and unresolved:

https://ortussolutions.atlassian.net/browse/CONTENTBOX-205

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

That’s a good question, but honestly it’s one that none of our solutions have addressed so far.

This is how I would handle it:
Create a backup folder and copy all files there that are about to be modified prior to the installation. The files can be copied back later on.

The database portion of the install can simply be rolled back with a transaction. To execute a “downgrade” two days later, you need to provide two methods in each update-- one to raise the version and one to lower the version. Ex. Add new records when increasing to the next version, or delete them back out when rolling back. Of course that can get sticky if the DB update destroys any data.

Look at how Ruby on Rails does it. They have an “up” method and a “down” method for applying the update either direction:
http://guides.rubyonrails.org/migrations.html

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

I guess the current way the DB gets updated is probably the best, once someone goes into production as in Martins case, I had already suggested the best option for his situation, that would work a treat. Which is why I asked if he was using MS SQL and showed him the blog posts I used.

The problem is deployment once into production, one has to be very careful when it comes to DB updates and why I prefer to use the DB tools, that are designed to do this job.

So if there are 5 updates to be applied, you are asking for 5 backup copies of the files? I guess if it is managed right it would work.

I would make separate backups. Let’s say you apply a “cumulative” update from version 1 to version 5 only to find out version 4 introduced a critical bug you can’t live with. Now you want to downgrade to version 3. You would have to be able to step down one update at a time. Now I supposed you could take the whole thing back down to 1 and step up to 3, but you wouldn’t need to if each update was atomic.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com