PrePersist / PostPersist / ... Semantics for Enitites

[greenrobot]

Callbacks for the entity class itself to organize its data.

The JPA equivalent would be the following annotations (http://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#Events), which we should should adapt:

• PostLoad
• PrePersist
• PostPersist
• PreUpdate
• PostUpdate
• PreRemove
• PostRemove

Thoughts on how to implement:

• Adapted method names (no parameters): postLoad, preInsert, postInsert, preUpdate, postUpdate, preDelete, postDelete
• It should probably be interface based, so entities can have any super class and optionally implement callbacks
• One option would be one interface per callback method
• Another option would be one interface for all callback methods which might be simpler
• Methods should be implemented in the keep sections of the entity
• AbstractDao knows which entities implement the interface(s) and calls the callbacks accordingly

Open questions:

• Single interface or interface per method?
• When should the callbacks for the Post* methods should be called? The straight forward way would be right after the SQL statement is issued. However, this might be strange when using transactions. The options are:
  • Right after the SQL statement was issued
  • Collect all modifications and trigger listeners before the TX is committed (JPA does it this way)
  • Collect all modifications and trigger listeners after the TX is committed successfully. From a user's perspective, I think this might be the best option.

This tickets relates to #44 (external listeners).

[croemmich]

I would do an single interface per method. I don't really like having a bunch of empty method bodies.

In AbstractDao, the instanceof operator could be used to determine if the entity should receive a specific callback. This would easily allow for superclasses to define callbacks with out requiring configuration during generation. If a user would like the entity itself to implement the interface, they could use the methods on the entity generation object "implementsPostLoad", "implementsPrePersist", etc.

After the TX commit seems reasonable to me, however, it could also make sense to do it when the identityScope is updated.. which I think is straight after the SQL statement.

[greenrobot]

OK, single interface per method sounds good.

I'd say, let's go with the simple solution and do the callback after the SQL statement (and identity scope). Let's don't worry about TXs for now - we could implement a more complex TxListener at a later point, too, which collects all updated, inserted, and deleted entities. Failing TXs are a nasty subject with ORMs....

[greenrobot]

Actually, I'm not totally convinced about the before or after TX topic. Have to give this a little more thought...

[croemmich]

After would almost certainly be best... however, I haven't looked through your code to see how difficult it would be.

[croemmich]

Here's how rails does it:
http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html#label-Transactions

From what I read, they essentially do everything right before and after the SQL statements. post* methods still have the ability to cancel the transaction.

[greenrobot]

I was just looking at JPA (http://download.oracle.com/otndocs/jcp/persistence-2.0-fr-eval-oth-JSpec/)...

Exceptions in callback/listeners seem always to rollback the TX (chapter 3.5), which might rule the "after-TX" option out. Still wondering why JPA does it after the individual calls. Maybe that's not a bad option after all.

[croemmich]

So thats two widely used mature ORMs.. maybe that's just how it's done It would sure be easier in any case. Though I like doing things the best way.. not the easiest.

[greenrobot]

This is also interesting: "The PreUpdate and PostUpdate callbacks occur before and after the database update operations to entity data respectively. These database operations may occur at the time the entity state is updated or they may occur at the time state is flushed to the database (which may be at the end of the transaction)." So, JPA doesn't even define the exact timing. We don't want to be better than JPA. ;) It seems we can stick to the simple solution. Just want to wait another day to see if something comes up. Also, maybe @yigit has an opinion on this?

[yigit]

we needed similar functionality in our Path fork and the way I implemented it is having an empty method in EntityBase class with name onBeforeSave.
when custom handling is required, we override that method on the Entity class. though this requires generating Entity and EntityBase classes where all properties/setters/getters are in EntityBase and Entity only has constructors and custom code with keep sections. I know you are not a big fan of Base class separation but it also lets us override setters-getters so it comes very handy.

base class could have a bunch of empty methods for each listener. when needed in code, custom @Override code could be added in Entity class to handle events.

To give a full example,

EntityBase has onBeforeSave method which is an empty method.
EntityDao 's bindValues method calls onBeforeSave on entity before binding variables.

after execute insert is run in AbstractDao, it can call onAfterSave for post processing. I find this approach clean and ~0 performance cost (no reflection etc)

I agree transactions are just too complex to handle properly.