Proposal: Support for lifecycle events

[jasperblues]

Suggest the ability to register any number of scheduled or on-commit lifecycle events in the run-loop. The code for this is already written in my forked neo4j-expire. It would need to be pulled into the framework.

Following that, it is very simple to provide an annotation-driven external interface with 'component scanning'. Something like:

Scheduled Event

@LifeCycleEvent(type=EventType.SCHEDULED,  nodes="hasLabel("Profile"), rels=Relationships.NONE)
public class ExpiryEvent  implements EventCallback {

        @Override
        public Long triggerDate(PropertyContainer pc) {
                //Eg, calculate trigger date as 'lastActive' property, minus 48 hours. 
                //If the property changes the index will be updated.  
        }

        //The event fired, do some work. 
        @Override
    public boolean applyIfNeeded(Node node) {
        //Eg set 'InactiveProfile' labels on the node, remove 'ActiveProfile' 
    }

        //EventCallback has an empty default impl, no need to ovverride. 
        @Override
    public boolean applyIfNeeded(Relationship node) {

    }

}

Commit Event

@LifeCycleEvent(type=EventType.BEFORE_COMMIT, 
nodes="hasLabel("Profile"), rels=Relationships.NONE)
public class RevivalEvent  implements EventCallback {

        //The event fired, do some work. 
        @Override
    public boolean applyIfNeeded(Node node) {
        //Eg check 'lastActive' and set 'ActiveProfile
    }
}

The expiry module could serve as an example of these capabilities, in just a few lines of code. There are already triggers (scheduled ones coming soon) in APOC, but the above feature could prove compelling for users of the GA framework.

Since most of the work is already done, wanted to know if a PR would be considered.

[ikwattro]

This is interesting.

I implemented an EventDispatcher in neo4j-nlp

https://github.com/graphaware/neo4j-nlp/blob/master/src/main/java/com/graphaware/nlp/module/NLPModule.java#L65

https://github.com/graphaware/neo4j-nlp/blob/master/src/main/java/com/graphaware/nlp/event/EventDispatcher.java#L47

I would be interested to see how it behaves with annotations, also the ability to define custom events. Agreed though that something generic in the framework could be useful

[jasperblues]

Thanks @ikwattro, I'll send a PR soon

[jasperblues]

Tests passing - just tidying up.

[jasperblues]

I submitted a PR. What do you think of:

• Using an interface, rather than annotations, to define events. (A future enhancement can add the ability to inject dependencies or configuration using annotations).
• Events are auto-registered using classpath scanning.
• Running the events as a module. Tighter integration?

Happy new year to you all btw 🎉

[bachmanm]

This is great @jasperblues, thank you very much. One thought: make the code a separate module and call it neo4j-lifecycle? Then make neo4j-expire obsolete or very minimalistic. I can merge this, but I'm not sure about having a module inside the framework, this would be the first one... thoughts @jasperblues @ikwattro ? If we all agree it should be outside the framework, I can do the work and create a separate module, push it, give credit to Jasper of course :)

[jasperblues]

The options are:

• Module in the framework (current state, after initial discussion).
• More tightly integrated into the framework (as a runloop or something).
• Separate module.

I don't mind which - feel free to choose whichever is appropriate after weighing up the pros and cons, and I'll send a new or modified PR.

[jasperblues]

Looking forward to your thoughts @ikwattro

In the meantime:

• Perhaps it is worth considering having the ability to inject type-safe @Value properties into module components, at a framework level. This is something to consider as a separate but related issue to where lifecycle should ultimately end up. If such a feature existed would @Value be appropriate or a framework specific one? I would lean towards a framework specific one, because . . .
• If there is a Spring context bound to the main ThreadLocal (@bachmanm ?) it could be used to perform DI and other configuration on module components, including regular @Value injection from a Spring context, and it would seem better to differentiate. Again, this would be something to consider at a framework level, regardless of lifecycle's final destination.

thanks fellers 👍 🙂

btw, I had to go ahead and upgrade to Neo4j 3.3 regardless of the module stuff, so I can check #86 later.

[ikwattro]

@jasperblues sorry I skipped this. external module is fine and I think @bachmanm already took some steps for that.

[jasperblues]

👍 OK, go ahead and do that, if you find it useful. And no need to worry about attribution.

[jasperblues]

https://github.com/jasperblues/neo4j-framework

^-- linking to the code, as there is no longer an open PR that points to it. Happy to help set up a module.

[bachmanm]

Hopefully this is now covered by https://github.com/graphaware/neo4j-triggers