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
- 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
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
> 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