4

We have a web application that uses Spring/JPA/Hibernate. Currently we are using SolidBase for database change management, which works well in a managed deployment model - however we are now migrating to a non-managed deployment model where users will be able to download the web application. We are building an "Update-Center" type functionality for the web application and are trying to figure out how we should apply database changes.

Ideally, I would like the application to apply any pending database changes at application startup and I would like this to be something that we can code pro grammatically but I don't want to rewrite Hibernate's SchemaExport functionality to do it.

Does anyone have any recommendations, patterns, or best practices on how we can best implement this functionality in to our application?

Is there any update-center application libraries that will solve our problem (I haven't been able to find a single one)?

Chris Schmidt
  • 398
  • 1
  • 12
  • Maybe you have a really good reason to do this. However here are my two cents. If you were to do schema updates during application start, you would need to give your "application/user" account DB owner access. This could expose some security holes in your application. I would suggest that you not change DB schema during application start. Or at least take care regarding what DB connection account you use. Personally, I do all DB schema updates outside of the application, i.e., manually - but that is just me. – Nabheet Dec 13 '12 at 21:01
  • That would be great if everyone managing the application happened to be a DBA - the problem is that it will be end-users maintaining the application. We need the ability to *push* updates to the application and it is pretty likely that a good portion of these updates to the application will have corresponding schema changes. There is already a data user and a schema user, the schema user is only ever used at application startup specifically for this task. – Chris Schmidt Dec 14 '12 at 02:21

2 Answers2

1

I discovered this article while researching this

http://www.infoq.com/news/upgrade-frameworks

This led me to this post

http://www.jroller.com/mrdon/entry/transparent_sql_schema_migration_with

Which ultimately led me to rolling my own solution to this problem using Apache DdlUtils and the BeanFactory solution offered in the jroller.com blog post.

This ultimately will be a component that can be dropped in to any application, legacy or new to implement update functionality into a web application. It will use XML to apply database updates and with the use of DDL it means that the package will work against any supported database. The updater will also support updates to filesystem resources and data itself (as opposed to schema)

Chris Schmidt
  • 398
  • 1
  • 12
0

I do not work for BitRock.

This may not be exactly what you are looking for, but I have used InstallBuilder from Bitrock to manage these types of updates for distributed applications. This is the same installer package that the PostgreSQL team uses. It was pretty straight forward to get this working, with minimal headaches. Especially when compared to other installer programs.

Woot4Moo
  • 23,987
  • 16
  • 94
  • 151
  • That looks interesting but it doesn't look like it solves the problem I have exactly. The unique piece of this puzzle is that it is a web application and so it has it's own set of requirements, namely that it must be something that can be directly integrated in to the application. – Chris Schmidt Dec 14 '12 at 19:21
  • @ChrisSchmidt Could you elaborate a bit more on what you mean by directly integrated? I suppose I am having a disconnect here since it is a distributed application that a user can have a local instance of that also communicates to the remote "mothership" correct? – Woot4Moo Dec 14 '12 at 19:26
  • Sure - so by directly integrated what I mean is that the functionality should exist within the application itself whereas in this package it is all maintained outside of the application. This is a web application that will more than likely be run on headless servers which make that a less than ideal situation for a CM to manage. The local instances do not communicate to the mothership *other* than to ask for updates. Does that answer your questions? – Chris Schmidt Dec 14 '12 at 23:25