Support of bitemporal pattern

[igm]

There's a Java framework done by Erwin Vervaet and Christophe
Vanfleteren related to bitemporal pattern implementation in Java
(https://svn.ervacon.com/public/projects/bitemporal/trunk/readme.txt).
The framework implements bitemporal pattern known from temporal
databases (http://en.wikipedia.org/wiki/Temporal_database) which in
short handles time dimension of data: validity period and record
period.
The BSD license is compatible with LGPL, so it should not be a problem
to incorporate the code in the project.

I suggest to incorporate some parts of the framework into DAO Fusion.
The suggested steps are:
* create experimental branch "branches/bitemporal"
* extend persistent entity model of DAO Fusion for bitemporal entities
* modify imported java source mainly in terms of class parametrization
and usage of annotations instead of .hbm.xml files

The branch should be maintained "below" the trunk according to the
"tofu scale" (http://www.perforce.com/perforce/conferences/us/2005/
presentations/Wingerd.pdf and
http://parleys.com/display/PARLEYS/Home#slide=1;title=Flow%20of%20Change;talk=1179649).

[vojtec...@gmail.com]

The bitemporal pattern is indeed very useful in real life applications
and I think it definitely makes sense to incorporate it into DAO
Fusion, given that original authors (Erwin Vervaet and Christophe
Vanfleteren) will be mentioned in modified classes.

The "bitemporal" branch below the trunk with any modifications of
imported bitemporal classes sounds good for me. In addition to this
step, I would also do this:
- include BSD license along LGPL license (*.txt files) in src/main/
resources
- create a new Reference document dedicated to the bitemporal pattern
(bitemporal class walkthrough + some simple examples)

> presentations/Wingerd.pdf andhttp://parleys.com/display/PARLEYS/Home#slide=1;title=Flow%20of%20Cha...).

[Igor Mihalik]

I propose one change to my previous suggestion. Instead of creating
new experimental branch below the trunk, I suggest to include
bitemporal directly in the trunk (SNAPSHOT).
My assumption is that bitemporal entities is the feature included in
the next release of DAO Fusion and thus it's not experimental. Other
reason is that inclusion of bitemporal support does not require
modification in existing code, it extends it.

[Michal Jemala]

Hello guys, I strongly recommend to add temporal aspects into DAOFusion. I gave bitemporal a glimpse and it seems to be very elegant a comprehensive way how to address temporal issues in domain models. In my opinion it is better idea to include bitemporal classes directly into the DAOFusion trunk. It will reduce confusion about library variants and versions. Also, as Igor mentioned, because it is possible to add Bitemporal without any further modification of existing classes I do not see any reasons to create experimental DAOFusion variant.

Another think I want to mention regards the statefullness of the API. Maybe I am mistaken but from that I have seen so far it seems that Bitemporal internals (e.g. BitemporalTrace class) use TimeUtils to get actual (or pre-set) time and date. This state is stored in thread local variable inside TimeUtils and has to be set up before using API. This brings some issues, such as: the same sequence of API calls with same data input could produce different outcome, if time reference inside TimeUtils is not set properly or simply forgotten. I am not saying that this approach is wrong, I just want to emphasize it and invoke some discussion to find out its flaws or strengths.

[vojtec...@gmail.com]

Hi guys, I think we can all agree that bitemporal pattern support will
be present in the next feature release of DAO Fusion (1.2). Just
before that, there will be a bugfix release (1.1.1) along with project
site updates. Therefore it makes sense to incorporate bitemporal
classes into the trunk as proposed with any modifications or
enhancements as appropriate.

Incorporating bitemporal classes into DAO Fusion also means:

- new dependency for daofusion-core (Joda Time)
- possibility to write white-box unit tests for core bitemporal logic
(e.g. BitemporalTrace)
- possibility to enhance core integration tests (sample eShop domain
model) with regard to bitemporal classes (maybe not necessary)


Michal, you are right, bitemporal internals use TimeUtils
(ThreadLocal<DateTime>) to set and get the reference time. Reference
time is used mostly for denoting the record time but can be used for
validity time as well (depends on method contract). I think using
reference time in ThreadLocal isn't bad idea because it prevents
bitemporal API pollution (user usually wants to work with current date/
time -- or more precisely, some reference time). Additionally, some
kind of reference time is also useful in case you work with this
reference on multiple places and want to ensure it is the same (e.g.
as opposed to calling new DateTime() multiple times in various
methods).

TimeUtils reference time therefore has to be set up properly before
using bitemporal logic.

"same sequence of API calls with same data input could produce
different outcome, if time reference inside TimeUtils is not set

properly or simply forgotten" - you are right

The user should be familiar with the bitemporal API and the concept of
reference/validity time. TimeUtils is useful because it stores the
time reference and user can navigate through time via this helper
class (no need to handle time references your own).

On Apr 22, 5:51 am, Michal Jemala <michal.jem...@gmail.com> wrote:
> Hello guys, I strongly recommend to add temporal aspects into DAOFusion.
> I gave bitemporal a glimpse and it seems to be very elegant a comprehensive
> way how to address temporal issues in domain models. In my opinion it is
> better idea to include bitemporal classes directly into the DAOFusion trunk.
> It will reduce confusion about library variants and versions. Also, as Igor
> mentioned, because it is possible to add Bitemporal without any further
> modification of existing classes I do not see any reasons to create
> experimental DAOFusion variant.
> Another think I want to mention regards the statefullness of the API. Maybe
> I am mistaken but from that I have seen so far it seems that Bitemporal
> internals (e.g. BitemporalTrace class) use TimeUtils to get actual (or
> pre-set) time and date. This state is stored in thread local variable inside
> TimeUtils and has to be set up before using API. This brings some issues,
> such as: the same sequence of API calls with same data input could produce
> different outcome, if time reference inside TimeUtils is not set properly or
> simply forgotten. I am not saying that this approach is wrong, I just want
> to emphasize it and invoke some discussion to find out its flaws or
> strengths.
>