This Week in Wonder

Every two weeks might make more sense, but as soon as I say that, they'll be a flurry of commits to Wonder and it will be a huge post :)

Migrations
Migrations were made more compatible for people not using ERPrototypes. One of the tricky parts of migrations is converting the API request into a database type (for instance, getting newStringColumn to turn into a VARCHAR in your db). EOF doesn't do a very good job at guessing these values, and in some cases it's impossible to guess. When you use ERPrototypes, we can secretly cheat and lookup some known prototype values. If you don't, though, we have to guess effectively. The guessing code was made better, as well as an explicit override for an unguessable type in Postgresql. So migrations should work properly for PG and FB (at least) even if you don't use ERPrototypes now.

Why aren't you using ERPrototypes again? When you use ERPrototypes, Entity Modeler will work more efficiently as well. For instance, when you create a new entity, it will automatically give you an "id" column that is of the "id" prototype.

Property Operators (Properators?)
There are certain cases where you want to be able to have conditional Properties, or properties that get processed in some special way at load time. Wonder now offers support for "property operators". Similar to NSArray operators, you can register operators that will allow you to convert, extend, modify, and add properties during the loading process.

As an example, you can register and use the "Encrypted" operator in your Application's static block (these have to load very early):

static {
ERXProperties.setOperatorForKey(new ERXProperties.EncryptedOperator(), ERXProperties.EncryptedOperator.Key);
}

and you can then specify properties like:

com.mdimension.somesecretvalue.@encrypted=akxb)*@HASBC*#@$&%&@(NSJKX&XZ#

which will use Wonder's default crypter to decrypt the value when it loads.

Or, if you happen to have, say, a really really big WO deployment, you may want to override properties based on instance range, so you can register the InRange operator named "forInstance":

static {
ERXProperties.setOperatorForKey(new ERXProperties.InRangeOperator(ERXProperties.intValueForKey("yourInstanceNumber")), ERXProperties.InRangeOperator.ForInstanceKey);
}

and make a property:
com.mdimension.somethingNotReadyForFullDeployment.@forInstance.100-500,1000-1500=sometestvalue

Note that instance number is a per-request concept, generally, so it's up to you to specify what "instance number" means to your app (so you would have to define and pass in instance number in Java Monitor). This is a pretty specialized feature, but if you have the problem, this should help.

You can write and register your own operators, though, so if you ever have to perform some processing on keys and values, you know where to look.