PrePersist / PostPersist / ... Semantics for Enitites about greendao HOT 9 OPEN

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.

from greendao.

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....

from greendao.

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

from greendao.

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

from greendao.

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.

from greendao.

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.

from greendao.

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.

from greendao.

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?

from greendao.

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.

from greendao.