google-code-export / morphia

Automatically exported from code.google.com/p/morphia
1 stars 0 forks source link

Add @EntityListeners #43

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Add @EntityListener support; works just like lifecycle methods but for 
another class.

@Entity
@EntityListeners(com.acme.AlertMonitor.class)
public class Account {
@Id long accountId;
}

public class AlertMonitor {
@PostPersist
public void newAccountAlert(Account acct) {
Alerts.sendMarketingInfo(acct.getAccountId(), acct.getBal-
ance());
}
}

Original issue reported on code.google.com by scotthernandez on 9 May 2010 at 5:41

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by scotthernandez on 10 May 2010 at 6:03

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r267.

Original comment by scotthernandez on 10 May 2010 at 6:42