On 2010-04-26 22.28, Niclas Hedhman wrote:
+ Clean up and tightening UnitOfWork semantics. For instance, what happens to an Entity instance after the UnitOfWork is completed?
It's dead. It only has validity in the context of a UoW.
Should we have 'detach' and possibly 'attach' semantics?
So that you can work on it while not in a UoW? I would really not encourage this. What we do have now is that if you have an entity reference from a completed UoW you can "renew it" by calling uow.get(entity) which will get you the same one in the given UoW. Is that enough?
How can we provide better lazy-loading support for Entitystore implementors?
Implementing some kind of caching helper would be nice. Pretty much all stores right now would benefit from it.
What about the earlier NestedUnitOfWork, can we sort that out? Should we?
I would suggest that we don't do that. It messes things up too much I think.
+ History support for Entities. Almost all apps I have ever worked on that use persistence, have had versioned stores. We should create the APIs and SPIs for this support.
Wouldn't it be enough to support EventSourcing? Or for what purpose do you want versioning of the state?
I have had great use of EventSourcing, in that services can subscribe and consume to events, but I'm not sure what to use versioned objects for. Any thoughts on that?
+ Events and remoting. I still think we should have explicit support for event management, both in-JVM as well as remotely. It is probably a fairly broad subject, from events being immutable entities to in-app signaling to cross-app transport/marshalling support. We should provide the APIs/SPIs for messaging and remoting implementations to things like JMS, MQ, CXF, RMI, Google Protocol Buffers and others, so that apps can be fully agnostic to underlying technology.
The EventSourcing lib I did in Streamflow could definitely be ported. But that's for domain events, rather than system events. What are the usecases you have in mind where Qi4j would come in?
For me these are (in that order) the top 3 "big things" at Core level we definitely should be working towards this year. There are of course bunches of smaller things, like fixing Indexing, make the libraries usable, auth/auth/audit support, documentation (big one), the IDEA support (sad it didn't get further), making Envisage usable as well remotely connectable, serialization of model to minimize start-up times (important in Google AppEngine)...
Yes, agree on all points.
So, to put the question back to you Phil; What do you have in mind of what we should do?
Yeah, that's important to know. What are you missing? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
