Hi Folks, We now have a situation where we deploy one solution both to on premises and cloud servers for different clients.
ClientA runs his own in house servers and we deploy remotely to him on MSSQL.
ClientB & C run a solution from our cloud server running Postgres.
Each client has their own Primary Db.
We are continuously developing and want to deploy to both types of clients ASAP after new additions, so we were wondering if anyone else has faced this scenario and answered the question of how best to keep Db structures in sync across multiple servers / server types?
Perhaps marking the Db’s ‘clone’ might keep them in sync, but since some are on different servers and of different types that’s probably a non starter? Perhaps simply importing the solution into each server should be sufficient to upgrade the structure of each Db - and marking the ones on the same server as ‘clone’ might solve the issue?
Robert has already pointed out some of the challenges we face with custom SQL between the two providers (cheers Bud), but I guess there must be a number of developers out there with the same challenge?
Any feedback, how-to’s or gotchas welcome - cheers in anticipation!
Great questions, but unfortunately not an easy answer I have dealt with variations of this. There are essentially 3-4 areas you need to deal with:
Solution Changes
DB Schema Changes
Plugin/Bean Changes
Jasper reports or other files
I have dealt with all of these building distributed Servoy Runtime updaters, however updating a server is a little different.
For Solution changes, I prefer overwriting the repository with one from your update, then you can use an HTTP post to update sequences. I don’t do this on a SaaS server, but if its something you want to be able to build into an actual installer/updater, then replacing the repository db is the easiest way to go since it has all the solution info in it.
For Schema changes, I keep a table with a version id in it. Then I have a method which builds the proper SQL query to update the schema. This way you can add, remove, or change columns. With solution import, you can only add.
Plugins and Beans are pretty easy as well. You can deal with that with a standard installer. Same with Jasper files.
Some people vary their installers by pulling down stuff from an FTP server instead of bundling it all in the installer.
You can use IzPack, the same installer Servoy uses to build your updater. You can start with PackJacket (free IzPack GUI tool) to get you started: http://packjacket.sourceforge.net/
The updater logic would go something like:
Shut down the Servoy Server (can be done with http post)
Install Plugins, Beans, Jasper files
Connect to the DB and replace the repository database
Connect to the DB and issue SQL statements to modify schema
Start up the server (wait for it to startup)
Use HTTP Post to update sequences
There is also a completely different approach available using the Maintenance Plugin. See: http://wiki.servoy.com/display/public/DOCS/maintenance
It provides pre, and post hooks to send notifications to clients, as well as updating schema, and dealing with cloned schemas. So, with this technique, you could…
Setup a solution to handle pre and post hooks
–*The pre hooks handle client alerts
–*The post hooks handle schema changes
Use HTTP Post to import solution into the repository
You could use the free FTP plugin to pull down plugins/beans/jasper reports down from your server
This could all be triggered from a client that clicks the “upgrade now” button in your solution.
Note: There is also a plugin to handle server restarts if you need it: mfServerUtils
Marking databases as a “clone of …” helps with keeping clones of a master database on the same server in sync, even if the clones are a (mix of) different brand(s) of database(s).
Now if you have multiple application Servers, just importing the solution on each one should be sufficient.
Marking databases as a “clone of …” helps with keeping clones of a master database on the same server in sync, even if the clones are a (mix of) different brand(s) of database(s).
Now if you have multiple application Servers, just importing the solution on each one should be sufficient.
Paul
Old post now Paul - but can you outline when the Clone Sever will be updated to the Master Structure? Is it on load of a given solution, start-up of the server or some other trigger???
Kahuna:
Old post now Paul - but can you outline when the Clone Sever will be updated to the Master Structure? Is it on load of a given solution, start-up of the server or some other trigger???
It happens when you import a new release of the solution and there are datamodel changes.
Using HTTP Post would be considered a hack and therefor it’s not documented.
Right now there is no real API for importing a solution into the repository database other than manually using the servoy-admin pages. I suggest you file a feature request with Servoy.