Configuration changes for zero.data
Abstract
This enhancement discusses configuration changes to
zero.data that would simplify development user experience and enable more flexibility as additional functionality is added to
zero.data.
Rationale
The configuration of databases in
zero.data is a flat map of properties and values as follows:
/config/db/reviewDB = {
"class" : "org.apache.derby.jdbc.EmbeddedDataSource",
"serverName" : "localhost",
"portNumber" : 1527
"databaseName" : "./db/review",
"createDatabase" : "create",
"password" : "<xor>Lz4sLCgwLTs="
}
The properties are used to hydrate a new
DataSource of the type specified in the "class" property. The GlobalContextManagerResolver implements a method that
knows that the "class" property is not actually a property on the and skips it when reflectively setting the attributes on the new
DataSource. This model does not provide for future enhancements to database configuration in
zero.data.
Proposed changes
The proposed change is to move the map of properties as follows:
/config/db/reviewDB = {
"factory" : "zero.data.factory.DataSourceFactory",
"dataSource" : "org.apache.derby.jdbc.EmbeddedDataSource",
"properties" : {
"serverName" : "localhost",
"portNumber" : 1527
"databaseName" : "./db/review",
"createDatabase" : "create",
"password" : "<xor>Lz4sLCgwLTs="
}
}
This makes it much more explicit to the developer what is the "dataSource" and what are the "properties". Further, by adding the "factory" attribute, this allows for further enhancements to take place. A reasonable default of the above class name makes the "factory" attribute optional.
For instance, if connection pooling is provided by an external third party API, Apache DBCP for instance, the configuration might be the following:
/config/db/reviewDB = {
"factory" : "com.xxx.yyy.DbcpFactory",
"dataSource" : "org.apache.derby.jdbc.EmbeddedDataSource",
"properties" : {
"serverName" : "localhost",
"portNumber" : 1527
"databaseName" : "./db/review",
"createDatabase" : "create",
"password" : "<xor>Lz4sLCgwLTs="
}
}
Backwards compatibility
Presently there are many applications already using the existing syntax. By deprecating the "class" attribute in favor of the new syntax, the existing syntax can still be supported. The above described factory implementation would be bypassed if the "class" attribute exists.