It is intended that CarrierWave will support a number of object persistence mechanisms. So far, you can configure one of these:
Configuration options and properties files have already been created in the vendor
directory and options commented out in the properties/default.properties
file. It is recommended that you consult these files, and the ANT targets in the
vendor/build.xml file.
CarrierWave ships with a JDOPersistenceSession that has been tested with the JDO "Reference Implementation" and the KODO JDO implementation.
You might find it useful to create a .build.properties file in the CarrierWave root directory, or your home directory with these value:
enabled.jdo=true #enabled.kodo=true #enabled.tjdo=true enabled.jdori=true
Also note that the vendor/build.xml has generic targets for jdo-enhance
and jdo-schema which default to whatever implementation is enabled.
But i recommend perusing the build.xml file to see everything it already
supports.
The JDO reference implementation (JDORI) can be found here. A few tests fail, but I don't believe the JDORI was intended for near production use.
Kodo is a product of SolarMetric. The latest version tested was 2.3.3. Currently some of the tests fail when accessing Maps of dependent types.
TJDO currently doesn't support either persisted Map or List types.
As of 1.1.4, Hibernate does not support "transparent" dependent types. In the case of one-to-one mappings, where an ImageableIdentifiable would reference an Imageable type, they must share a common object id. CarrierWave does a depth first modify on object graphs. Any new dependent objects are created before their parent object and do not have the benefit of knowing their parents object id. Possibly a more complex method of updates can be employed in a future release, but for now it is recommended that all business objects be ImageableIdentifiable.
Also note, for complex type hierarchies, (it seems that) Hibernate only supports one table per class heirarchy.
Last Modified: 11/27/2002