I think this is a step in the correct direction. But I am not sure if
there will be found API satisfying all possible entitystores. Like,
should there be a way for end-users to customize how history is stored
(separate file/table or some other way), should there be there any
additional information than just timestamp (and could that be customized
as well?), etc. But definetly worth a try IMO.
Quoting Niclas Hedhman <[email protected]>:
Gang,
this will be a proposal requiring some guts and a lot of thinking.
I have previous mentioned that I would like to see "timeseries"
support in Qi4j, but could at that time not formulate it well enough.
Now I think I can.
We see more and more applications requiring that "no data to be lost"
and that full history of all changes are kept permanently. I.e. both
DELETE and UPDATE in SQL are no longer to be used. I think Qi4j can
introduce the support for data evolution quite easily, especially
compared to Hibernate and other ORM frameworks, which are two
"shallow" to model it. SO;
1. Introduce the concept of "asOf" in UnitOfWork, and if specified the
UoW will become readOnly and not tolerate any modifications. It simply
will tell the persistence system to bring back the state at a
particular point in the past.
DateTime lastWeek = ... ;
UnitOfWork uow = module.newUnitOfWork().asOf( lastWeek );
or possibly
DateTime lastWeek = ... ;
UnitOfWork uow = module.newUnitOfWork( lastWeek );
but I prefer the former.
2. Introduce
<T> TimeSeries<T> timeSeries( Property<T> entityProperty,
Interval range );
which returns all values of a given property between certain
datetimes. This method probably goes into UnitOfWork.
Since the Property can only contain values, the returned TimeSeries
should probably also be a Value and not tied to UnitOfWork, BUT there
could be advantages to allow a link to exist to an underlying "cursor"
so everything doesn't need to fit in memory.That is a topic for
discussion and innovative solutions (like the new support for
Associations in Values).
So in action that would look like;
Interval lastSixMonths = ....;
UnitOfWork uow = module.currentUnitOfWork();
Account account = uow.get(Account.class, "12345" );
TimeSeries<Double> history = uow.timeSeries( account.balance(),
lastSixMonths );
for( Point<Double> p : history )
plot( p.timestamp(), p.value() );
3. To support both of these, the Persistence SPI barely needs any
changes, since it is currently passing down the CRUD operations, but
the generic MapEntityStore that most implementations utilize will need
to be modified accordingly. And all EntityStores should support this
feature (optionally to be turned off if disk space is a concern).
I think it makes a lot of sense to push this into 2.0, since it will
break data storage, as transitions are to be kept instead of state.
But it is not a small undertaking...
WDYAT??
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
