Stomp

Managing multiple databases and development environments.

One complexity which Stomp handles well is managing multiple databases. Many production environments have many persistent objects, mapped to many different databases, which need to interact seamlessly. Besides this, the databases used during development and production are often (I hope!) located in different places. These different installations all have the same schema, but serve different purposes (development vs qa vs production).

So for each database we need a different properties file. Beyond that, we actually need many different properties files for each database, one each for development, qa, and production! How do you manage all these properties files? Stomp makes it easy, by introducing two basic ideas: “system state” and “schema group”.

The “system state” concept. This is a pref in your runtime.prefs file. Look in this minimal runtime prefs file and you can’t miss this setting. This is how you tell Stomp whether you are currently operating in a development, qa, or production mode. Switching back and forth between these modes is as simple as changing this pref.

How does Stomp know what properties file to use? It combines your setting of the system state, with the schema group of the object in question…

The “schema group” concept. Stomp groups all the identical development, qa, and production databases into one “schema group”. This group is then named, with the default group being named “stomp”. You can specify, in your services.xml file, the schema group of the objects being tagged for enhancement, like this:

<services>

<Foo>

<schemaGroup>myGroup</schemaGroup>

</Foo>

</services>

Stomp now knows that objects of class “Foo” are part of the “myGroup” schema group. When you make a query with Foo.class, look up an object by id, get an Extent, whatever, Stomp is able to find the schema group you provided in the services.xml file and use that in determining the properties file to use.

Choosing a properties file. Now… the moment of truth. You’ve asked for an Extent of Foo.class objects. Stomp checks your services.xml file and finds that Foo is in the “myGroup” schemaGroup. It then checks the setting of the system state and sees that you are working in development. It combines these two flags and looks up the jdoFactory.properties.myGroup.development runtime preference. This will have a value like “myGroup-development.properties”, which you will have to write and make available on the CLASSPATH. Once you have written these properties files for each combination of schema group / system state that you choose to have, you are done. Objects in different schema groups can play together in the same JVM with ease. Changing from development to production is a snap. Can you dig it?

While we’re on the subject of properties files, I’ll take a moment to point out that the properties files you write for Kodo need some particular settings to work well with Stomp. See the article on configuring your data cache for more details.