Craig Miskell writes:
> module names should be fairly unique anyway
> (perhaps a recommendation in the documentation to store the xyz.somext in
> the "package" with the DataObject classes so that there is even less
> chance of conflict?)
Yeah, this is a good idea.
As for customizing deployment, we just need to define what needs to be
customized. How about this:
1. DataDomain becomes a main deployment unit. It links all the relevant
information together. All we need to add is a way to import DataMaps from a
module.
2. Just like now, a project may have multiple "domains".
3. We introduce a concept of a "default" domain (I had it before the first
release, but it "got lost" along the way). If a project has only a single
domain, it is always default.
4. Default domain can be specified as a system property:
java -Dcayenne.domain.default=production com.foo.MyApp
This way you can customize *every* deployment aspect by having a separate
domain for it. Things easily customizable are:
* DataSourceFactory
* factory-specific settings
* adapter class
[This doesn't solve password security issues, unless JNDI is used.]
Having an "autodetect" adapter is possible for the driver-based nodes
(checking for the list of known driver implementations or parsing DB URL). I
have no idea how to do this for JNDI connections though. I guess we can
implement a partial "autodetection" mechanism for DataNodes that have no
adapter selected:
node.setAdapter(DataSourceFactory.guessAdapter());
Andrus
This archive was generated by hypermail 2.0.0 : Tue Oct 29 2002 - 15:49:12 EST