Extend Mapping classes or implement custom strategies?

[Yuri <yd...@gmail.com>]

Hi, 

Since a few days back I started looking into extending OpenJPA to support
transaction time state tables, but am struggling a bit to define the best
strategy going forward. 

My initial idea is to create a @Temporal annotation that generates a
slightly modified table schema and SQL statements for an entity. Consider
the following example:

@Entity
@Temporal(name="valid")
class Entity {
   @Id
   private String id;
   @Basic
   private String name;
}

The end result of adding @Temporal should be two additional columns
(validStart and validEnd), a modified primary key/unique constraint (id and
validEnd). The infrastructure should make sure that inserts/updates/deletes
correctly map modified SQL statements with values automatically generated
for validStart and validEnd.

I am a bit unsure about the best approach to implement this using OpenJPA
and would appreciate some directions if any.

My first tentative was to create a TemporalFullClassStrategy (one for each
existing class strategy would be needed) to map the additional
columns/pks/joinable to Table and ClassMapping following a bit how
DatastoreId does it, i.e. creating columns, and manufacturing a primaryKey.
Here I was partially successful. The primary key (Id and validEnd) are
correctly created in the db, but validStart was not created at all. I am
also not sure if there is a way to automatically set the defaults for these
strategies in code instead of requiring the user to explicitly define them.

In the @DatastoreId case, the added column is always the only primarykey
column and maps nicely to the StoreManager.oid as the internal field storage
(since the class itself doesnt have it). In my case above, I need to
transparently "extend" whatever Id the user has defined to include validEnd
being that id a simple @Id, an @IdClass or even a @DatastoreId although I am
not too worried about that at the moment.

Am I in the right path here? More specifically:
- is a custom ClassStrategy impl the right approach or is it a bit limiting
considering that I may need to get at the gut of OpenJPA to change some of
its semantics? 
- Should I take the approach of extending MappingRepository, ClassMapping,
FieldMapping and possibly other classes too?
- Does it make more sense or is it a better/simpler approach to force the
entity to declare the temporal fields (validStart and validEnd) instead of a
class level @Temporal(name="valid")? One goal was to keep the temporality
totally orthogonal to the model hence the idea to keek the temporal fields
out of the class completely, but if this goal is going to complicate the
implementation a bit I would prefer the simpler approach at least initially.
- What is the best place to store validStart and validEnd state considering
that the persistent class does not have these fields or may not have them.
Would a custom StoreManager be the right place?
- Is there any documentation/pointers to design/dev information beyond what
I already found in the std documentation page of OpenJPA?

Any help would be greatly appreciated!

Thanks in advance,

-- yuri






-- 
View this message in context: http://n2.nabble.com/Extend-Mapping-classes-or-implement-custom-strategies--tp1518056p1518056.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

Re: Extend Mapping classes or implement custom strategies?

[Pinaki Poddar <pp...@apache.org>]

> That makes me think whether using a custom VersionStrategy could be what I
need. 

Perhaps yes. At least will be the right starting point to begin further
exploration. It is worthwhile to note that recently support for Version that
spans multiple columns has been added.[1][2]

[1]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_mapping_custom_versdiscrim
[2] https://issues.apache.org/jira/browse/OPENJPA-697



Yuri wrote:
> 
> 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--tp1518056p1519765.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

Re: Extend Mapping classes or implement custom strategies?

[Yuri <yd...@gmail.com>]

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.

Re: Extend Mapping classes or implement custom strategies?

[Pinaki Poddar <pp...@apache.org>]

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--tp1518056p1518264.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.