Well, these were the kind of questions I would like to get input on, what is it that you need. But since I am a user as well as a designer of this I guess I could go ahead and answer these questions from my perspective. I'll do so inline.
On Wed, Mar 31, 2010 at 5:26 PM, Rick Bullotta < rick.bullo...@burningskysoftware.com> wrote: > Hi, Tobias. > > That's awesome news. > > A few general questions regarding an event framework for Neo4J... > > - In the current implementation, there's a thread affinity for > transactions. > I am guessing that this could create big challenges for "proactive" > handlers > that are potentially executed on a different thread? > My thinking around this is that the event handlers would get access to some sort of objects that represent the changes made in the transaction. These objects would be possible to access outside of a transactional context. The Proactive handlers would however have to be executed synchronously in the same thread. The reactive handlers would execute on a different thread, and for them it would be nice to be able to operate on the graph without needing a transactional context, but I guess opening a read transaction isn't that big of a deal here anyway, so I think it will work out. > - Will the handlers be synchronous or asynchronous? I answered this above... > > - Also, another consideration is whether or not you want to provide support > for event "folding" for chatty changes to properties on nodes/relationships > (e.g. you choose the quality of service - all changes or most recent > changes > only if you haven't yet processed the mutation event). > I would like to keep the number of events fired to as low as possible, meaning that a onNodePropertyChage() event is probably too chatty, onBeforeWriteTransactionCommit(SomeObjectWithTheChanges) is probably a better level. But any input on what you would need is useful. So I would say that you would only observe the changes that were present at commit, and no events would be fired before commit. > - What do you envision passing along with events? A full "copy" of the > node/relationship? Only the mutated property? > If we can keep it to only be the mutated state that would be great. If we can limit ourselves to "the node with this ID changed somehow" that would be even better. Actually I think we could limit ourselves to that since the proactive events could be fired (in the same thread as the transaction is executing in) while the transaction is still open, meaning that the modified nodes and relationships are still available, and in the reactive handlers you could open a transaction to get to the current state (the changed state might already be stale anyway). > > - Would there be support for "bucketed" notifications that would allow > notifications on multiple property changes on a node to be processed as a > single entity? > See my answer to the "folding" question. > > Looking forward to seeing how this all materializes! > > Rick > > > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On > Behalf Of Tobias Ivarsson > Sent: Wednesday, March 31, 2010 6:39 AM > To: Neo user discussions > Subject: [Neo] Requirements for an event framework for Neo4j > > Fellow developers! > > The time has come to start the work on an event framework for Neo4j. In > order to do a good work at this we would get input on what requirements you > have on an event framework. We would like to get a list of use cases for > which you would use an event framework, along with the features you think > the use case would need from the event framework (i.e. which events you > would like to receive notification about, and when). We would also like you > to motivate why these features are required by the use case. Events can > easily degrade performance if the framework is ill designed, so we would > like to keep things very lean. > > We have made some early analysis and arrived at the following conclusions: > > * There can be two kinds of event handlers: Proactive event handlers and > Reactive event handlers. > Proactive event handlers have the ability to preempt operations and > Reactive > event handlers simply react to an event and cannot cause the event to not > succeed. > > * There are three kinds of events in Neo4j kernel: > - Lifecycle events, such as shutdown. > - Transactional events, such as start commit, commit successful, rollback, > etc. > - Data modification events, such as node created, property changed, > relationship removed, etc. > > It might be possible that other components, such as the indexing component, > would want to add more events to the event framework. > > These are of course just some initial input to get your thoughts going, > feel > free to think outside of the constraints above. Our ultimate goal is to > create an event framework that is as useful as possible while maintaining > > -- > Tobias Ivarsson <tobias.ivars...@neotechnology.com> > Hacker, Neo Technology > www.neotechnology.com > Cellphone: +46 706 534857 > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Tobias Ivarsson <tobias.ivars...@neotechnology.com> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
