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.