On 5/2/12 23:02 , Niclas Hedhman wrote:
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.
I think this is already in v2.0, in the sense that you can start a UoW
with a given time. in UoWF:
UnitOfWork newUnitOfWork(long currentTime);
EntityStore has also been updated with this. Implementations don't
handle it yet, but at least the API/SPI should be fine.
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() );
No opinion on this one right now. If the above makes you happy, I'm happy.
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).
See above.
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??
Well, as above, the main changes are already in there. I won't have much
time (as you know) to work on it, but I agree with the basic premise and
importance of the feature.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
