That makes me think whether using a custom VersionStrategy could be what I need. Adding temporality to a persistent class does affect version and I also see that StateManager already has a _version field where I could store a custom Version instance that holds for the validStart and validEnd. Here I am assuming that VersionStrategy.map() can then synthetically add the validEnd, validStart field mappings to ClassMapping and adjust primary key and unique constraint.
Humm, I guess it would still make more sense to have a single @Temporal annotation at the class level that would setup the ClassMapping, FieldMappings and the proper version strategy otherwise the user would have to declare a version field with a specific Version object. I still need to figure out how to add a new custom annotation and override the default strategies with temporal ones. Can ProductDerivation help in any way here or should I stay away from it? I was gong the nuclear path of extending ProductDerivation, Configuration, MappingRepository, ClassMapping, etc, etc. thanks for you help! -- yuri Pinaki Poddar wrote: > > Hi, > An analogous usage is VersionStrategy. > May be you should also refer to Custom Field Mapping [1] > Adding extra temporal data to every instance is most likely can be > accomplished by adding extra field mapping to an annotated class. So > effectively the annotation should result in adding extra field mapping to > ClassMapping. Then the user need not to declare fields for the temporal > state. > > [1] > http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_mapping_custom_field > > > -- View this message in context: http://n2.nabble.com/Extend-Mapping-classes-or-implement-custom-strategies--tp1518056p1519426.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
