Tomasz Slota's Weblog
« May 2006 »
MonTueWedThuFriSatSun
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
26
27
28
29
30
31
    
       
Today

XML

the links

Skype Me™!
View Tomasz Slota's profile on LinkedIn



All | NetBeans | Personal | Sun

20060501 Monday May 01, 2006

Problems with Version Control in Enterprise Applications

I used to do a year long internship in a Latin American banking software company. As an "outsider with a fresh look" I was occasionally asked to try to think of better ways of doing certain things that were causing them most troubles. One of such areas was version control. Updates sent out to the customers, in spite of rigorous procedures in place, were continuously causing inconsistencies between the database schema and client application layers (and thus annoying runtime exceptions). I developed an auto update tool and carried on later writing a Master's Thesis on some ideas of how to develop a self-updating, portable version control system for database schema. Once quite proud of the solutions I had come up with, I could never help the feeling that much simplier, "Egg of Columbus" style solution existed but I was failing to see it.

Now as I am working with the new EJB3/Java Persistence APIs I am starting to see a light in the end of tunnel... There is no longer need to maintain the database schema and application sources separately. The latter can be generated automatically from the sources. The consequences of this fact are depeer than just saving the time needed for manual schema creation - the source code duality problem (DDL SQL vs logic language like Java or PL/SQL) disappers, it is easier to handle sources manually as well as using modern, static analysis based tools.

I can imagine design patterns like "Versioned Entity Manager" that would look up and persist entities in a schema version dependent way. The mechanism could be possibly transparent to the developers and upper architecture layers. Perhabs one day such a mechanism could be incorporated into a standard application container...

A common database application development scenario is that the ORM mapping is pretty straightforward in the beginning and then gets complicated as the system is optimized for performance and is updated to keep some additional data. This case seems to be able to be handled very nicely. However there are still many corners (like renaming/removing tables/columns) that at least for now would require some special, conscious handling.

I wonder if anyone has come up with/is working on some smart ways of handling such problems. Looking forward to your comments!

Posted by tomslot ( May 01 2006, 12:01:52 PM CEST ) Permalink Comments [0]