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.
> On Tue, Apr 21, 2009 at 8:33 PM, Igor Mihalik <igor.miha...@gmail.com>wrote:
> > 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.
> > On Apr 20, 11:19 am, vojtech.sz...@gmail.com wrote:
> > > 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)
> > > On Apr 20, 9:55 am, igm <igor.miha...@gmail.com> wrote:
> > > > 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 andhttp://
> > parleys.com/display/PARLEYS/Home#slide=1;title=Flow%20of%20Cha...).
