Closed GoogleCodeExporter closed 9 years ago
actually (as mentioned on the ml) it would be good for a Listener to be able to
replace the entity, like
public Account newAccountAlert(Account acct)
furthermore, i think it would be good if those listeners could be defined to be
used
on every mapped entity by programmatically adding it to morphia itself.
why not having an interface for that, but using @prePersist? i did not get this
design decision in JPA as well.
Furthermore i´d suggest wrapping the Entity into an LifecycleEvent-object for
the API
to evolve easier.
Original comment by google-a...@codesmell.de
on 9 May 2010 at 7:07
I don't like the idea of your entity being replace (whole-sale) like that. For
one,
the current implementation of DAO/Datastore.save() don't return the entity
(they are
void, and Key<E> at the moment).
This also has a (significant) impact on client code and causes a strange
situate
where you just can't fire off a save and let the rest of you code interact with
that
"old" instance of the entity. It means that everywhere you save you must return
the
entity and update all references of it. Not very intuitive or easy.
We can start with the simple support for EntityListeners; maybe along that way
we can
find extension points that could allow you to change this behavior as you would
like.
There is nothing keeping you from implementing your own DAO/Datastore wrapper
that
does this.
Original comment by scotthernandez
on 9 May 2010 at 9:33
It would be good to let your DI container instantiate the Listener classes
(often they will need external resources
injected). Need to think about the best way to allow for that, because it is
quite an essential requirement.
Original comment by oli.ga...@gmail.com
on 10 May 2010 at 10:43
Original comment by scotthernandez
on 10 May 2010 at 6:03
This issue was closed by revision r267.
Original comment by scotthernandez
on 10 May 2010 at 6:42
Original issue reported on code.google.com by
scotthernandez
on 9 May 2010 at 5:41