Pelle Poluha wrote:
And this side effect also works:abstract class MessageSideEffect extends ConcernOf<MessageBehaviour> implements MessageBehaviour { String giveMeContent() { println "sideeffect in action" return null } }
You are calling it "side-effect", but the code does "extends ConcernOf" instead of SideEffectOf. Are you declaring the above using @SideEffects() annotation on the Composite type? If so that shouldn't work. If it does we need to fix so that Qi4j complains when Concerns are used as SideEffects.
Meaning migration still is a problem? How do you usually solve data migration after class changes?
Migration of data is still not done, as Niclas said. We are getting closer to having really nice hooks for doing it though. So far data migration has to be done by manually exporting, updating and importing the state. No tools for it yet though, other than the REST support which makes import/export reasonably easy.
What about ListAssocation and SetAssociation? Aren't those persisted? If only the references are persisted, does that mean that I have to wire the associated entities back together myself after retrieval? Is it done by searching for the reference id:s? I really would like to have an object graph back from the store.
There are many levels of references. On a persistence level only the id's of the referenced Entities are persisted. But when you access that through Association or ManyAssociation that will be converted into live Java objects that are strongly typed. In other words, from an application developers point of view it *is* an object graph.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
