I am using the event framework to auto-index nodes based on a special name i
give the properties: Whenever i want a property to be indexed, i append
:index=<name> to the property-name. On afterCommit() i check all changed
properties, and re-index the values that have changed. Really simple and
smooth, the framework makes it really easy.

BTW.: I wrote a new IndexService using BabuDB [1]. BabuDB is really fast,
but does not work for fulltext query. For now the IndexService is embedded
in the Object-graph mapper i wrote [2]. Anyone is free to check it out, if
it looks interesting it could be moved to a neo4j subproject.

-atle


[1] http://code.google.com/p/babudb/
<http://code.google.com/p/babudb/>[2] http://ogrm.org


On Thu, Apr 29, 2010 at 2:08 PM, Atle Prange <atle.pra...@gmail.com> wrote:

> Fixed, nice :)
>
> atle
>
>
> On Thu, Apr 29, 2010 at 12:16 PM, Mattias Persson <
> matt...@neotechnology.com> wrote:
>
>> Oo, wait a minute... I saw the problem. Try again with the latest code
>> (just
>> committed)!
>>
>> 2010/4/29 Atle Prange <atle.pra...@gmail.com>
>>
>> > Really nice, but it seems that afterCommit() never receives any data,
>> the
>> > TransactionData argument is always null..
>> >
>> > On Tue, Apr 27, 2010 at 10:15 AM, Mattias Persson <
>> > matt...@neotechnology.com
>> > > wrote:
>> >
>> > > Hi everyone!
>> > >
>> > > I'm quite pleased to announce that the new event framework has been
>> > > committed in kernel 1.1-SNAPSHOT. After feedback from you guys the
>> > > framework
>> > > got quite small and cosy. Here's a summary.
>> > >
>> > > *TransactionEventHandler*
>> > > can be registered at a GraphDatabaseService and will thereafter
>> recieve
>> > > diffs of modifications made in each transaction before and after they
>> are
>> > > committed. The transaction can still be modified in beforeCommit() and
>> > that
>> > > method can also throw an exception to prevent the transaction from
>> > > committing, causing a TransactionFailureException to be thrown from
>> the
>> > > code
>> > > which is committing the transaction.
>> > >
>> > > *KernelEventHandler*
>> > > can be registered at a GraphDatabaseService and will receive
>> > notifications
>> > > about when a shutdown is about to occur for the GraphhDatabaseService
>> > > instance. It will also receive notifications about "kernel panics"
>> which
>> > is
>> > > a state which the kernel can come to from where it cannot continue
>> > without
>> > > needing to be restarted. An example of such an error would be a hard
>> > drive
>> > > breakdown or when no more space is left on the device the graph
>> database
>> > is
>> > > running on.
>> > >
>> > > The next step is to write an "auto indexer" for the IndexService so
>> that
>> > > that you won't have to do the manual indexService.index( node, key,
>> value
>> > )
>> > > anymore. Another thing would be to remove (deprecate) the
>> > > IndexService#shutdown() method as it no longer would be required.
>> > >
>> > > So it'd be great if you guys would try this out and tell us how it
>> feels.
>> > >
>> > > --
>> > > Mattias Persson, [matt...@neotechnology.com]
>> > > Hacker, Neo Technology
>> > > www.neotechnology.com
>> > > _______________________________________________
>> > > 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
>> >
>>
>>
>>
>> --
>> Mattias Persson, [matt...@neotechnology.com]
>> Hacker, Neo Technology
>> www.neotechnology.com
>> _______________________________________________
>> 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

Reply via email to