Quoting Rickard Öberg <[email protected]>:
On 2010-07-09 16.14, Stanislav Muhametsin wrote:
I've considered extended composites too. It's almost good enough - but
what happens when someone gets immutable query composite and says
uow.remove(iq)? When I give IQ to someone, I don't want it to be
removable (well, at least in 99% of cases :) ).
Making IQ's mixin implement Lifecycle and throwing exception in remove()
could be one solution, but then the IQ's Lifecycle's overridden remove()
will throw exception also in case when entity gets removed via
command-role, right?
If you want to be really safe I would actually recommend that
application code is not doing the UoW handling, i.e. you have
something in front of your app code that does UoW start and
complete/discard. This is what we do in our REST API (GET=uow
start+discard,POST/PUT/DELETE=uow start+complete). Then no matter
what the code does in response to GET the changes will be discarded
anyway.
/Rickard
Hmm, that might be a solution, as long as I assume that uow.complete()
won't be called from app code either. I'll look into that.
As a related note, could be @UnitOfWorkPropagation annotation be then
modified so that it would take parameter like "end action", which
would be either discard, or complete the UoW? Currently the
UnitOfWorkConcern discards UoW only if exception is thrown.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
