[Neo4j] java.io.IOException: Resource temporarily unavailable in MappedPersistenceWindow.java?

[Paul Bandler]

When running a test neo4j application on Solaris that I have previously run 
successfully on Windows I'm encountering the following exception:

Caused by: java.io.IOException: Resource temporarily unavailable
at sun.nio.ch.FileChannelImpl.map0(Native Method)
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:747)
at 
org.neo4j.kernel.impl.nioneo.store.MappedPersistenceWindow.(MappedPersistenceWindow.java:53)

Indeed this in  turn is causing a huge knock-on effect but I've not included 
that stack trace for clarity.  The program appears to attempt to continue, 
albeit at a snails pace.

I'm running using the latest 1.4 milestone release, with a maximum heap of 2G, 
and defaulting all other store parameters.

Any suggestions as to what is happening would be most welcome.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Moving a Neo4j Database?

[Paul Bandler]

Ignore this post - user error...!

On 29 Jun 2011, at 22:09, Paul Bandler wrote:

> Is there some record within the Neo4J database or its indexing that retains 
> knowledge of the location where it was created?  Only I tried coping a neo4j 
> database from a Windows drive to a Unix file system and started a Unix neo4j 
> application pointing to it and while it connected apparently ok, when it 
> tried to find its first index it failed to find it, even though I can clearly 
> see the relevant Index files in its filesystem area.  Also I notice in the 
> neo4j startup that it reports its 'store_dir' property as referencing the 
> Windows drive and directory from whence it originated
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Problems building neo4j-rdf module

[Thomas Fritz]

Hello

I am also interesed in testing Neo4J as a RDF Triple Store.
Thanks Marco for pointing to this.

If we use the Ouplementation of Tinkerpop for Sail and Neo4J, are there any
features Neo4J offers or performance optimizations or other things we can
not use in such a setup?
I think i have read somewhere, also i could not find it again that indexing
is not supported?

Is it possible to use also cypher besides sparql in such a setup?



Kind regards



---

*Thomas FRITZ*
*web* http://fritzthomas.com
*twitter* http://twitter.com/thomasf



2011/6/29 Marko Rodriguez 

> Hi,
>
> This is the link:
>https://github.com/tinkerpop/blueprints/wiki/Sail-Ouplementation
>
> The other one was for making an RDF triple/quad store look like a property
> graph database.
>
> If you are familiar with OpenRDF's Sail, then the take home point is:
>
> Sail sail = new GraphSail(new Neo4jGraph('/tmp/mygraph'));
>
> At which point, sail provides the RDF layer for inferencing, SPARQL, RQL,
> loading/saving RDF, etc.
>
> See ya,
> Marko.
>
> http://markorodriguez.com
>
> On Jun 29, 2011, at 1:03 PM, Nikola Milikic wrote:
>
> > Hi,
> >
> > Thanks for the reply!
> >
> > I'm not familiar with Thinkerpop, but I'll give it a try. My intention
> was
> > just to check out the performance neo4j would give when working with RDF
> > data, but to be honest, on a first glimpse, this looks over too
> complicated
> > for just reading some RDF data into a store.
> >
> > Best,
> > Nikola
> >
> >
> > On Tue, Jun 28, 2011 at 3:13 PM, Mattias Persson
> > wrote:
> >
> >> Another option could be to run it through the Tinkerpop stack and get
> >> access
> >> to a Sail with neo4j underneath that way. I think it's more up to date.
> >>
> >> https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation
> >>
> >> 2011/6/28 Nikola Milikic 
> >>
> >>> Hi all,
> >>>
> >>> I wanted to try out neo4j-rdf library and found somewhere that there
> are
> >> no
> >>> official releases, but the library should be built from the source (
> >>> https://svn.neo4j.org/components/rdf/trunk). But when I checked out
> the
> >>> project, it reported dependency problems as some of the dependencies
> are
> >>> not
> >>> available. After I changed them to the ones available from the Maven
> >>> Central, then I got compilation errors.
> >>>
> >>> Did anyone face with the same problem and knows how to resolve this?
> Or,
> >>> better would be if somebody could provide me with builded jar.
> >>>
> >>> Thanks a lot for the help!
> >>>
> >>> Best,
> >>> Nikola Milikic
> >>>
> >>>
> >>> Nikola Milikic, BSc
> >>> Teaching Assistant
> >>> University of Belgrade, Serbia
> >>> 
> >>> email: nikola.mili...@gmail.com
> >>> URL:   nikola.milikic.info
> >>> ___
> >>> Neo4j mailing list
> >>> User@lists.neo4j.org
> >>> https://lists.neo4j.org/mailman/listinfo/user
> >>>
> >>
> >>
> >>
> >> --
> >> Mattias Persson, [matt...@neotechnology.com]
> >> Hacker, Neo Technology
> >> www.neotechnology.com
> >> ___
> >> Neo4j mailing list
> >> User@lists.neo4j.org
> >> https://lists.neo4j.org/mailman/listinfo/user
> >>
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] neo4j-graph-collections

[Niels Hoogeveen]

Great... Looking forward to your contributions. Once the port is done, we can 
look at making improvements.

> From: sxk1...@hotmail.com
> Date: Wed, 29 Jun 2011 16:34:39 -0700
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> I'm definitely interested and will contact you soon to follow up.
> 
> Sent from my iPhone
> 
> On Jun 29, 2011, at 4:17 PM, Craig Taverner  wrote:
> 
> > I think moving the RTree to the generic collections would not be too hard. I
> > saw Saikat showed interested in doing this himself.
> > 
> > Saikat, contact me off-list for further details on what I think could be
> > done to make this port.
> > 
> > On Wed, Jun 29, 2011 at 9:52 PM, Niels Hoogeveen
> > wrote:
> > 
> >> 
> >> Peter, I totally agree. Having the Rtree index removed of spatial
> >> dependencies in graph-collections should be our first priority. Once that 
> >> is
> >> done we can focus on the other issues.
> >> Which doesn't mean we should stop discussing future improvements like
> >> setting up comparators (or something to that extent) that can be reusable,
> >> but we shouldn't try to get that up before Rtree is in graph-collections.
> >> Niels
> >> 
> >>> From: peter.neuba...@neotechnology.com
> >>> Date: Wed, 29 Jun 2011 21:10:15 +0200
> >>> To: user@lists.neo4j.org
> >>> Subject: Re: [Neo4j] neo4j-graph-collections
> >>> 
> >>> Craig,
> >>> just gave you push access to the graph collections in case you want to
> >>> do anything there.
> >>> 
> >>> Also, IMHO it would be more important to isolate and split out the
> >>> RTree component from Spatial than to optimize it - that could be done
> >>> in the new place with targeted performance tests later?
> >>> 
> >>> Cheers,
> >>> 
> >>> /peter neubauer
> >>> 
> >>> GTalk:  neubauer.peter
> >>> Skype   peter.neubauer
> >>> Phone   +46 704 106975
> >>> LinkedIn   http://www.linkedin.com/in/neubauer
> >>> Twitter  http://twitter.com/peterneubauer
> >>> 
> >>> http://www.neo4j.org   - Your high performance graph
> >> database.
> >>> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> >>> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
> >>> 
> >>> 
> >>> 
> >>> On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
> >>>  wrote:
>  
>  Craig,
>  Would it be possible to merge your work on Amanzi with the work the Neo
> >> team has done on the Btree component that is now in 
> >> neo4j-graph-collections,
> >> so we can eventually have one implementation that meets a broad variety of
> >> needs?
>  Niels
>  
> > Date: Wed, 29 Jun 2011 15:34:47 +0200
> > From: cr...@amanzi.com
> > To: user@lists.neo4j.org
> > Subject: Re: [Neo4j] neo4j-graph-collections
> > 
> > I have previously used two solutions to deal with multiple types in
> >> btrees:
> > 
> >   - My first index in 2009 was a btree-like n-dim index using
> >> generics to
> >   support int[], long[], float[] and double[] (no strings). I used
> >> this for
> >   TimeLine (long[1]) and Location (double[2]). The knowledge about
> >> what type
> >   was used was in the code for constructing the index (whether a new
> >> index or
> >   accessing an existing index in the graph).
> >   - In December I started my amanzi-index (on
> > github)
> >   that is also btree-like, n-dimensional. But this time it can index
> >> multiple
> >   types in the same tree (so a float, int and string in the same
> >> tree, instead
> >   of being forced to have all properties of the same type). It is a
> >> re-write
> >   of the previous index to support Strings, and mixed types. This
> >> time it does
> >   save the type information in meta-data at the tree root.
> > 
> > The idea of using a 'comparator' class for the types is similar, but
> >> simpler
> > than the idea I implemented for amanzi-index, where I have mapper
> >> classes
> > that describe not only how to compare types, but also how to map from
> >> values
> > to index keys and back. This includes (to some extent) the concept of
> >> the
> > lucene analyser, since the mapper can decide on custom distribution
> >> of, for
> > example, strings and category indexes.
> > 
> > For both of these indexes, you configure the index up front, and then
> >> only
> > call index.add(node) to index a node. This will fit in well with the
> >> new
> > auto-indexing ideas in neo4j.
> > 
> > On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> > wrote:
> > 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> At this moment Btree only supports the primitive datatype long,
> >> while Rtree
> >> only supports the datatype double. For Btree it makes sense to at
> >> least
> >> support strings, floats, doubles and ints too. Use cases for these
> >> data
> >> types are pretty obvious and are Btree ba

Re: [Neo4j] neo4j-graph-collections

[Niels Hoogeveen]

Let me first look into the details of the current Btree implementation and see 
how it can be expanded to other datatypes, then look into your typing support 
in Amanzi and figure out if they match. If so we can port those parts to 
graph-collections.

> Date: Thu, 30 Jun 2011 01:15:31 +0200
> From: cr...@amanzi.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> It is technically possible, but it is a somewhat specialized index, not a
> normal BTree, so I think you would want both (mine and a classic btree). My
> index performs better for certain data patterns, is best with semi-ordered
> data and moderately even distributions (since it has no rebalancing), and
> requires the developer to pick a good starting 'resolution' which means they
> should know something about their data. Perhaps we just port some of the
> typing support into a btree in the collections project?
> 
> On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
> wrote:
> 
> >
> > Craig,
> > Would it be possible to merge your work on Amanzi with the work the Neo
> > team has done on the Btree component that is now in neo4j-graph-collections,
> > so we can eventually have one implementation that meets a broad variety of
> > needs?
> > Niels
> >
> > > Date: Wed, 29 Jun 2011 15:34:47 +0200
> > > From: cr...@amanzi.com
> > > To: user@lists.neo4j.org
> > > Subject: Re: [Neo4j] neo4j-graph-collections
> > >
> > > I have previously used two solutions to deal with multiple types in
> > btrees:
> > >
> > >- My first index in 2009 was a btree-like n-dim index using generics
> > to
> > >support int[], long[], float[] and double[] (no strings). I used this
> > for
> > >TimeLine (long[1]) and Location (double[2]). The knowledge about what
> > type
> > >was used was in the code for constructing the index (whether a new
> > index or
> > >accessing an existing index in the graph).
> > >- In December I started my amanzi-index (on
> > > github)
> > >that is also btree-like, n-dimensional. But this time it can index
> > multiple
> > >types in the same tree (so a float, int and string in the same tree,
> > instead
> > >of being forced to have all properties of the same type). It is a
> > re-write
> > >of the previous index to support Strings, and mixed types. This time
> > it does
> > >save the type information in meta-data at the tree root.
> > >
> > > The idea of using a 'comparator' class for the types is similar, but
> > simpler
> > > than the idea I implemented for amanzi-index, where I have mapper classes
> > > that describe not only how to compare types, but also how to map from
> > values
> > > to index keys and back. This includes (to some extent) the concept of the
> > > lucene analyser, since the mapper can decide on custom distribution of,
> > for
> > > example, strings and category indexes.
> > >
> > > For both of these indexes, you configure the index up front, and then
> > only
> > > call index.add(node) to index a node. This will fit in well with the new
> > > auto-indexing ideas in neo4j.
> > >
> > > On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > At this moment Btree only supports the primitive datatype long, while
> > Rtree
> > > > only supports the datatype double. For Btree it makes sense to at least
> > > > support strings, floats, doubles and ints too. Use cases for these data
> > > > types are pretty obvious and are Btree backed in (almost) every RDBMS
> > > > product around.I think the best solution would be to create Comparator
> > > > objects wrapping these primitive data types and store the class name of
> > the
> > > > comparator in root of the index tree. This allows users to create their
> > own
> > > > comparators for datatypes not covered yet. It would make sense people
> > would
> > > > want to store BigInt and BigDecimal objects in a Btree too, others may
> > want
> > > > to store dates (instead of datetime), fractions, complex numbers or
> > even
> > > > more exotic data types.
> > > > Niels
> > > > > From: sxk1...@hotmail.com
> > > > > To: user@lists.neo4j.org
> > > > > Date: Tue, 28 Jun 2011 22:43:24 -0700
> > > > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > > >
> > > > >
> > > > > I've read through this thread in more detail and have a few thoughts,
> > > > when you talk about type I am assuming that you are referring to an
> > > > interface that both (Btree,Rtree) can implement, for the data types I'd
> > like
> > > > to understand the use cases first before implementing the different
> > data
> > > > types, maybe we could store types of Object instead of Long or Double
> > and
> > > > implement comparators in a more meaningful fashion.   Also I was
> > wondering
> > > > if unit tests would need to be extracted out of the spatial component
> > and
> > > > embedded inside the graph-collections component as well or whether we'd
> >

Re: [Neo4j] neo4j-graph-collections

[Saikat Kanjilal]

I'm definitely interested and will contact you soon to follow up.

Sent from my iPhone

On Jun 29, 2011, at 4:17 PM, Craig Taverner  wrote:

> I think moving the RTree to the generic collections would not be too hard. I
> saw Saikat showed interested in doing this himself.
> 
> Saikat, contact me off-list for further details on what I think could be
> done to make this port.
> 
> On Wed, Jun 29, 2011 at 9:52 PM, Niels Hoogeveen
> wrote:
> 
>> 
>> Peter, I totally agree. Having the Rtree index removed of spatial
>> dependencies in graph-collections should be our first priority. Once that is
>> done we can focus on the other issues.
>> Which doesn't mean we should stop discussing future improvements like
>> setting up comparators (or something to that extent) that can be reusable,
>> but we shouldn't try to get that up before Rtree is in graph-collections.
>> Niels
>> 
>>> From: peter.neuba...@neotechnology.com
>>> Date: Wed, 29 Jun 2011 21:10:15 +0200
>>> To: user@lists.neo4j.org
>>> Subject: Re: [Neo4j] neo4j-graph-collections
>>> 
>>> Craig,
>>> just gave you push access to the graph collections in case you want to
>>> do anything there.
>>> 
>>> Also, IMHO it would be more important to isolate and split out the
>>> RTree component from Spatial than to optimize it - that could be done
>>> in the new place with targeted performance tests later?
>>> 
>>> Cheers,
>>> 
>>> /peter neubauer
>>> 
>>> GTalk:  neubauer.peter
>>> Skype   peter.neubauer
>>> Phone   +46 704 106975
>>> LinkedIn   http://www.linkedin.com/in/neubauer
>>> Twitter  http://twitter.com/peterneubauer
>>> 
>>> http://www.neo4j.org   - Your high performance graph
>> database.
>>> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
>>> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>>> 
>>> 
>>> 
>>> On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
>>>  wrote:
 
 Craig,
 Would it be possible to merge your work on Amanzi with the work the Neo
>> team has done on the Btree component that is now in neo4j-graph-collections,
>> so we can eventually have one implementation that meets a broad variety of
>> needs?
 Niels
 
> Date: Wed, 29 Jun 2011 15:34:47 +0200
> From: cr...@amanzi.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> I have previously used two solutions to deal with multiple types in
>> btrees:
> 
>   - My first index in 2009 was a btree-like n-dim index using
>> generics to
>   support int[], long[], float[] and double[] (no strings). I used
>> this for
>   TimeLine (long[1]) and Location (double[2]). The knowledge about
>> what type
>   was used was in the code for constructing the index (whether a new
>> index or
>   accessing an existing index in the graph).
>   - In December I started my amanzi-index (on
> github)
>   that is also btree-like, n-dimensional. But this time it can index
>> multiple
>   types in the same tree (so a float, int and string in the same
>> tree, instead
>   of being forced to have all properties of the same type). It is a
>> re-write
>   of the previous index to support Strings, and mixed types. This
>> time it does
>   save the type information in meta-data at the tree root.
> 
> The idea of using a 'comparator' class for the types is similar, but
>> simpler
> than the idea I implemented for amanzi-index, where I have mapper
>> classes
> that describe not only how to compare types, but also how to map from
>> values
> to index keys and back. This includes (to some extent) the concept of
>> the
> lucene analyser, since the mapper can decide on custom distribution
>> of, for
> example, strings and category indexes.
> 
> For both of these indexes, you configure the index up front, and then
>> only
> call index.add(node) to index a node. This will fit in well with the
>> new
> auto-indexing ideas in neo4j.
> 
> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> wrote:
> 
>> 
>> 
>> 
>> 
>> 
>> At this moment Btree only supports the primitive datatype long,
>> while Rtree
>> only supports the datatype double. For Btree it makes sense to at
>> least
>> support strings, floats, doubles and ints too. Use cases for these
>> data
>> types are pretty obvious and are Btree backed in (almost) every
>> RDBMS
>> product around.I think the best solution would be to create
>> Comparator
>> objects wrapping these primitive data types and store the class name
>> of the
>> comparator in root of the index tree. This allows users to create
>> their own
>> comparators for datatypes not covered yet. It would make sense
>> people would
>> want to store BigInt and BigDecimal objects in a Btree too, others
>> may want
>> to store dates (instead of datetime), fractions, comple

Re: [Neo4j] neo4j-graph-collections

[Craig Taverner]

I think moving the RTree to the generic collections would not be too hard. I
saw Saikat showed interested in doing this himself.

Saikat, contact me off-list for further details on what I think could be
done to make this port.

On Wed, Jun 29, 2011 at 9:52 PM, Niels Hoogeveen
wrote:

>
> Peter, I totally agree. Having the Rtree index removed of spatial
> dependencies in graph-collections should be our first priority. Once that is
> done we can focus on the other issues.
> Which doesn't mean we should stop discussing future improvements like
> setting up comparators (or something to that extent) that can be reusable,
> but we shouldn't try to get that up before Rtree is in graph-collections.
> Niels
>
> > From: peter.neuba...@neotechnology.com
> > Date: Wed, 29 Jun 2011 21:10:15 +0200
> > To: user@lists.neo4j.org
> > Subject: Re: [Neo4j] neo4j-graph-collections
> >
> > Craig,
> > just gave you push access to the graph collections in case you want to
> > do anything there.
> >
> > Also, IMHO it would be more important to isolate and split out the
> > RTree component from Spatial than to optimize it - that could be done
> > in the new place with targeted performance tests later?
> >
> > Cheers,
> >
> > /peter neubauer
> >
> > GTalk:  neubauer.peter
> > Skype   peter.neubauer
> > Phone   +46 704 106975
> > LinkedIn   http://www.linkedin.com/in/neubauer
> > Twitter  http://twitter.com/peterneubauer
> >
> > http://www.neo4j.org   - Your high performance graph
> database.
> > http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> > http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
> >
> >
> >
> > On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
> >  wrote:
> > >
> > > Craig,
> > > Would it be possible to merge your work on Amanzi with the work the Neo
> team has done on the Btree component that is now in neo4j-graph-collections,
> so we can eventually have one implementation that meets a broad variety of
> needs?
> > > Niels
> > >
> > >> Date: Wed, 29 Jun 2011 15:34:47 +0200
> > >> From: cr...@amanzi.com
> > >> To: user@lists.neo4j.org
> > >> Subject: Re: [Neo4j] neo4j-graph-collections
> > >>
> > >> I have previously used two solutions to deal with multiple types in
> btrees:
> > >>
> > >>- My first index in 2009 was a btree-like n-dim index using
> generics to
> > >>support int[], long[], float[] and double[] (no strings). I used
> this for
> > >>TimeLine (long[1]) and Location (double[2]). The knowledge about
> what type
> > >>was used was in the code for constructing the index (whether a new
> index or
> > >>accessing an existing index in the graph).
> > >>- In December I started my amanzi-index (on
> > >> github)
> > >>that is also btree-like, n-dimensional. But this time it can index
> multiple
> > >>types in the same tree (so a float, int and string in the same
> tree, instead
> > >>of being forced to have all properties of the same type). It is a
> re-write
> > >>of the previous index to support Strings, and mixed types. This
> time it does
> > >>save the type information in meta-data at the tree root.
> > >>
> > >> The idea of using a 'comparator' class for the types is similar, but
> simpler
> > >> than the idea I implemented for amanzi-index, where I have mapper
> classes
> > >> that describe not only how to compare types, but also how to map from
> values
> > >> to index keys and back. This includes (to some extent) the concept of
> the
> > >> lucene analyser, since the mapper can decide on custom distribution
> of, for
> > >> example, strings and category indexes.
> > >>
> > >> For both of these indexes, you configure the index up front, and then
> only
> > >> call index.add(node) to index a node. This will fit in well with the
> new
> > >> auto-indexing ideas in neo4j.
> > >>
> > >> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> > >> wrote:
> > >>
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > At this moment Btree only supports the primitive datatype long,
> while Rtree
> > >> > only supports the datatype double. For Btree it makes sense to at
> least
> > >> > support strings, floats, doubles and ints too. Use cases for these
> data
> > >> > types are pretty obvious and are Btree backed in (almost) every
> RDBMS
> > >> > product around.I think the best solution would be to create
> Comparator
> > >> > objects wrapping these primitive data types and store the class name
> of the
> > >> > comparator in root of the index tree. This allows users to create
> their own
> > >> > comparators for datatypes not covered yet. It would make sense
> people would
> > >> > want to store BigInt and BigDecimal objects in a Btree too, others
> may want
> > >> > to store dates (instead of datetime), fractions, complex numbers or
> even
> > >> > more exotic data types.
> > >> > Niels
> > >> > > From: sxk1...@hotmail.com
> > >> > > To: user@lists.neo4j.org

Re: [Neo4j] neo4j-graph-collections

[Craig Taverner]

It is technically possible, but it is a somewhat specialized index, not a
normal BTree, so I think you would want both (mine and a classic btree). My
index performs better for certain data patterns, is best with semi-ordered
data and moderately even distributions (since it has no rebalancing), and
requires the developer to pick a good starting 'resolution' which means they
should know something about their data. Perhaps we just port some of the
typing support into a btree in the collections project?

On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
wrote:

>
> Craig,
> Would it be possible to merge your work on Amanzi with the work the Neo
> team has done on the Btree component that is now in neo4j-graph-collections,
> so we can eventually have one implementation that meets a broad variety of
> needs?
> Niels
>
> > Date: Wed, 29 Jun 2011 15:34:47 +0200
> > From: cr...@amanzi.com
> > To: user@lists.neo4j.org
> > Subject: Re: [Neo4j] neo4j-graph-collections
> >
> > I have previously used two solutions to deal with multiple types in
> btrees:
> >
> >- My first index in 2009 was a btree-like n-dim index using generics
> to
> >support int[], long[], float[] and double[] (no strings). I used this
> for
> >TimeLine (long[1]) and Location (double[2]). The knowledge about what
> type
> >was used was in the code for constructing the index (whether a new
> index or
> >accessing an existing index in the graph).
> >- In December I started my amanzi-index (on
> > github)
> >that is also btree-like, n-dimensional. But this time it can index
> multiple
> >types in the same tree (so a float, int and string in the same tree,
> instead
> >of being forced to have all properties of the same type). It is a
> re-write
> >of the previous index to support Strings, and mixed types. This time
> it does
> >save the type information in meta-data at the tree root.
> >
> > The idea of using a 'comparator' class for the types is similar, but
> simpler
> > than the idea I implemented for amanzi-index, where I have mapper classes
> > that describe not only how to compare types, but also how to map from
> values
> > to index keys and back. This includes (to some extent) the concept of the
> > lucene analyser, since the mapper can decide on custom distribution of,
> for
> > example, strings and category indexes.
> >
> > For both of these indexes, you configure the index up front, and then
> only
> > call index.add(node) to index a node. This will fit in well with the new
> > auto-indexing ideas in neo4j.
> >
> > On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> > wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > At this moment Btree only supports the primitive datatype long, while
> Rtree
> > > only supports the datatype double. For Btree it makes sense to at least
> > > support strings, floats, doubles and ints too. Use cases for these data
> > > types are pretty obvious and are Btree backed in (almost) every RDBMS
> > > product around.I think the best solution would be to create Comparator
> > > objects wrapping these primitive data types and store the class name of
> the
> > > comparator in root of the index tree. This allows users to create their
> own
> > > comparators for datatypes not covered yet. It would make sense people
> would
> > > want to store BigInt and BigDecimal objects in a Btree too, others may
> want
> > > to store dates (instead of datetime), fractions, complex numbers or
> even
> > > more exotic data types.
> > > Niels
> > > > From: sxk1...@hotmail.com
> > > > To: user@lists.neo4j.org
> > > > Date: Tue, 28 Jun 2011 22:43:24 -0700
> > > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > >
> > > >
> > > > I've read through this thread in more detail and have a few thoughts,
> > > when you talk about type I am assuming that you are referring to an
> > > interface that both (Btree,Rtree) can implement, for the data types I'd
> like
> > > to understand the use cases first before implementing the different
> data
> > > types, maybe we could store types of Object instead of Long or Double
> and
> > > implement comparators in a more meaningful fashion.   Also I was
> wondering
> > > if unit tests would need to be extracted out of the spatial component
> and
> > > embedded inside the graph-collections component as well or whether we'd
> > > potentially need to write brand new unit tests as well.
> > > > Craig as I mentioned I'd love to help, let me know if it would be
> > > possible to fork a repo or to talk in more detail this week.
> > > > Regards
> > > >
> > > > > From: pd_aficion...@hotmail.com
> > > > > To: user@lists.neo4j.org
> > > > > Date: Wed, 29 Jun 2011 01:35:43 +0200
> > > > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > > >
> > > > >
> > > > > As to the issue of n-dim doubles, it would be interesting to
> consider
> > > creating a set of classes of type Orderable (supporting <, <=, >, >=
> > > operations), this we can 

[Neo4j] Moving a Neo4j Database?

[Paul Bandler]

Is there some record within the Neo4J database or its indexing that retains 
knowledge of the location where it was created?  Only I tried coping a neo4j 
database from a Windows drive to a Unix file system and started a Unix neo4j 
application pointing to it and while it connected apparently ok, when it tried 
to find its first index it failed to find it, even though I can clearly see the 
relevant Index files in its filesystem area.  Also I notice in the neo4j 
startup that it reports its 'store_dir' property as referencing the Windows 
drive and directory from whence it originated
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Problems building neo4j-rdf module

[Marko Rodriguez]

Hi,

This is the link:
https://github.com/tinkerpop/blueprints/wiki/Sail-Ouplementation

The other one was for making an RDF triple/quad store look like a property 
graph database.

If you are familiar with OpenRDF's Sail, then the take home point is:

Sail sail = new GraphSail(new Neo4jGraph('/tmp/mygraph'));

At which point, sail provides the RDF layer for inferencing, SPARQL, RQL, 
loading/saving RDF, etc.

See ya,
Marko.

http://markorodriguez.com

On Jun 29, 2011, at 1:03 PM, Nikola Milikic wrote:

> Hi,
> 
> Thanks for the reply!
> 
> I'm not familiar with Thinkerpop, but I'll give it a try. My intention was
> just to check out the performance neo4j would give when working with RDF
> data, but to be honest, on a first glimpse, this looks over too complicated
> for just reading some RDF data into a store.
> 
> Best,
> Nikola
> 
> 
> On Tue, Jun 28, 2011 at 3:13 PM, Mattias Persson
> wrote:
> 
>> Another option could be to run it through the Tinkerpop stack and get
>> access
>> to a Sail with neo4j underneath that way. I think it's more up to date.
>> 
>> https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation
>> 
>> 2011/6/28 Nikola Milikic 
>> 
>>> Hi all,
>>> 
>>> I wanted to try out neo4j-rdf library and found somewhere that there are
>> no
>>> official releases, but the library should be built from the source (
>>> https://svn.neo4j.org/components/rdf/trunk). But when I checked out the
>>> project, it reported dependency problems as some of the dependencies are
>>> not
>>> available. After I changed them to the ones available from the Maven
>>> Central, then I got compilation errors.
>>> 
>>> Did anyone face with the same problem and knows how to resolve this? Or,
>>> better would be if somebody could provide me with builded jar.
>>> 
>>> Thanks a lot for the help!
>>> 
>>> Best,
>>> Nikola Milikic
>>> 
>>> 
>>> Nikola Milikic, BSc
>>> Teaching Assistant
>>> University of Belgrade, Serbia
>>> 
>>> email: nikola.mili...@gmail.com
>>> URL:   nikola.milikic.info
>>> ___
>>> Neo4j mailing list
>>> User@lists.neo4j.org
>>> https://lists.neo4j.org/mailman/listinfo/user
>>> 
>> 
>> 
>> 
>> --
>> Mattias Persson, [matt...@neotechnology.com]
>> Hacker, Neo Technology
>> www.neotechnology.com
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>> 
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] neo4j-graph-collections

[Niels Hoogeveen]

Peter, I totally agree. Having the Rtree index removed of spatial dependencies 
in graph-collections should be our first priority. Once that is done we can 
focus on the other issues.
Which doesn't mean we should stop discussing future improvements like setting 
up comparators (or something to that extent) that can be reusable, but we 
shouldn't try to get that up before Rtree is in graph-collections.
Niels

> From: peter.neuba...@neotechnology.com
> Date: Wed, 29 Jun 2011 21:10:15 +0200
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> Craig,
> just gave you push access to the graph collections in case you want to
> do anything there.
> 
> Also, IMHO it would be more important to isolate and split out the
> RTree component from Spatial than to optimize it - that could be done
> in the new place with targeted performance tests later?
> 
> Cheers,
> 
> /peter neubauer
> 
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
> 
> http://www.neo4j.org   - Your high performance graph database.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
> 
> 
> 
> On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
>  wrote:
> >
> > Craig,
> > Would it be possible to merge your work on Amanzi with the work the Neo 
> > team has done on the Btree component that is now in 
> > neo4j-graph-collections, so we can eventually have one implementation that 
> > meets a broad variety of needs?
> > Niels
> >
> >> Date: Wed, 29 Jun 2011 15:34:47 +0200
> >> From: cr...@amanzi.com
> >> To: user@lists.neo4j.org
> >> Subject: Re: [Neo4j] neo4j-graph-collections
> >>
> >> I have previously used two solutions to deal with multiple types in btrees:
> >>
> >>- My first index in 2009 was a btree-like n-dim index using generics to
> >>support int[], long[], float[] and double[] (no strings). I used this 
> >> for
> >>TimeLine (long[1]) and Location (double[2]). The knowledge about what 
> >> type
> >>was used was in the code for constructing the index (whether a new 
> >> index or
> >>accessing an existing index in the graph).
> >>- In December I started my amanzi-index (on
> >> github)
> >>that is also btree-like, n-dimensional. But this time it can index 
> >> multiple
> >>types in the same tree (so a float, int and string in the same tree, 
> >> instead
> >>of being forced to have all properties of the same type). It is a 
> >> re-write
> >>of the previous index to support Strings, and mixed types. This time it 
> >> does
> >>save the type information in meta-data at the tree root.
> >>
> >> The idea of using a 'comparator' class for the types is similar, but 
> >> simpler
> >> than the idea I implemented for amanzi-index, where I have mapper classes
> >> that describe not only how to compare types, but also how to map from 
> >> values
> >> to index keys and back. This includes (to some extent) the concept of the
> >> lucene analyser, since the mapper can decide on custom distribution of, for
> >> example, strings and category indexes.
> >>
> >> For both of these indexes, you configure the index up front, and then only
> >> call index.add(node) to index a node. This will fit in well with the new
> >> auto-indexing ideas in neo4j.
> >>
> >> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> >> wrote:
> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > At this moment Btree only supports the primitive datatype long, while 
> >> > Rtree
> >> > only supports the datatype double. For Btree it makes sense to at least
> >> > support strings, floats, doubles and ints too. Use cases for these data
> >> > types are pretty obvious and are Btree backed in (almost) every RDBMS
> >> > product around.I think the best solution would be to create Comparator
> >> > objects wrapping these primitive data types and store the class name of 
> >> > the
> >> > comparator in root of the index tree. This allows users to create their 
> >> > own
> >> > comparators for datatypes not covered yet. It would make sense people 
> >> > would
> >> > want to store BigInt and BigDecimal objects in a Btree too, others may 
> >> > want
> >> > to store dates (instead of datetime), fractions, complex numbers or even
> >> > more exotic data types.
> >> > Niels
> >> > > From: sxk1...@hotmail.com
> >> > > To: user@lists.neo4j.org
> >> > > Date: Tue, 28 Jun 2011 22:43:24 -0700
> >> > > Subject: Re: [Neo4j] neo4j-graph-collections
> >> > >
> >> > >
> >> > > I've read through this thread in more detail and have a few thoughts,
> >> > when you talk about type I am assuming that you are referring to an
> >> > interface that both (Btree,Rtree) can implement, for the data types I'd 
> >> > like
> >> > to understand the use cases first before impl

Re: [Neo4j] infinitegraph vs neo4j vs orientdb

[Jim Webber]

Hello Aliabbas,

I don't believe Neo4j is suited to single clusters with petabytes of data. It's 
possible but impractical because we scale for reads through replicas and 
cache-sharding. And petabyte replicas are impractical.

Jim
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] New to graph databases

[Jim Webber]

Hi René,

The only difference between what I advocate and your direction connections is 
depth. You're (implicitly) looking to work at depth 1, whereas I'm suggesting 
that (weighted) paths at deeper levels can be just as useful (and since Neo4j 
makes traversing cheap, that additional depth often won't hurt). 

What my proposal does is open up the data for other, serendipitous re-uses of 
the data since all the entities are there. 

Does that help to clarify a little?

Jim
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] neo4j-graph-collections

[Peter Neubauer]

Craig,
just gave you push access to the graph collections in case you want to
do anything there.

Also, IMHO it would be more important to isolate and split out the
RTree component from Spatial than to optimize it - that could be done
in the new place with targeted performance tests later?

Cheers,

/peter neubauer

GTalk:      neubauer.peter
Skype       peter.neubauer
Phone       +46 704 106975
LinkedIn   http://www.linkedin.com/in/neubauer
Twitter      http://twitter.com/peterneubauer

http://www.neo4j.org               - Your high performance graph database.
http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.



On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
 wrote:
>
> Craig,
> Would it be possible to merge your work on Amanzi with the work the Neo team 
> has done on the Btree component that is now in neo4j-graph-collections, so we 
> can eventually have one implementation that meets a broad variety of needs?
> Niels
>
>> Date: Wed, 29 Jun 2011 15:34:47 +0200
>> From: cr...@amanzi.com
>> To: user@lists.neo4j.org
>> Subject: Re: [Neo4j] neo4j-graph-collections
>>
>> I have previously used two solutions to deal with multiple types in btrees:
>>
>>    - My first index in 2009 was a btree-like n-dim index using generics to
>>    support int[], long[], float[] and double[] (no strings). I used this for
>>    TimeLine (long[1]) and Location (double[2]). The knowledge about what type
>>    was used was in the code for constructing the index (whether a new index 
>> or
>>    accessing an existing index in the graph).
>>    - In December I started my amanzi-index (on
>> github)
>>    that is also btree-like, n-dimensional. But this time it can index 
>> multiple
>>    types in the same tree (so a float, int and string in the same tree, 
>> instead
>>    of being forced to have all properties of the same type). It is a re-write
>>    of the previous index to support Strings, and mixed types. This time it 
>> does
>>    save the type information in meta-data at the tree root.
>>
>> The idea of using a 'comparator' class for the types is similar, but simpler
>> than the idea I implemented for amanzi-index, where I have mapper classes
>> that describe not only how to compare types, but also how to map from values
>> to index keys and back. This includes (to some extent) the concept of the
>> lucene analyser, since the mapper can decide on custom distribution of, for
>> example, strings and category indexes.
>>
>> For both of these indexes, you configure the index up front, and then only
>> call index.add(node) to index a node. This will fit in well with the new
>> auto-indexing ideas in neo4j.
>>
>> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
>> wrote:
>>
>> >
>> >
>> >
>> >
>> >
>> > At this moment Btree only supports the primitive datatype long, while Rtree
>> > only supports the datatype double. For Btree it makes sense to at least
>> > support strings, floats, doubles and ints too. Use cases for these data
>> > types are pretty obvious and are Btree backed in (almost) every RDBMS
>> > product around.I think the best solution would be to create Comparator
>> > objects wrapping these primitive data types and store the class name of the
>> > comparator in root of the index tree. This allows users to create their own
>> > comparators for datatypes not covered yet. It would make sense people would
>> > want to store BigInt and BigDecimal objects in a Btree too, others may want
>> > to store dates (instead of datetime), fractions, complex numbers or even
>> > more exotic data types.
>> > Niels
>> > > From: sxk1...@hotmail.com
>> > > To: user@lists.neo4j.org
>> > > Date: Tue, 28 Jun 2011 22:43:24 -0700
>> > > Subject: Re: [Neo4j] neo4j-graph-collections
>> > >
>> > >
>> > > I've read through this thread in more detail and have a few thoughts,
>> > when you talk about type I am assuming that you are referring to an
>> > interface that both (Btree,Rtree) can implement, for the data types I'd 
>> > like
>> > to understand the use cases first before implementing the different data
>> > types, maybe we could store types of Object instead of Long or Double and
>> > implement comparators in a more meaningful fashion.   Also I was wondering
>> > if unit tests would need to be extracted out of the spatial component and
>> > embedded inside the graph-collections component as well or whether we'd
>> > potentially need to write brand new unit tests as well.
>> > > Craig as I mentioned I'd love to help, let me know if it would be
>> > possible to fork a repo or to talk in more detail this week.
>> > > Regards
>> > >
>> > > > From: pd_aficion...@hotmail.com
>> > > > To: user@lists.neo4j.org
>> > > > Date: Wed, 29 Jun 2011 01:35:43 +0200
>> > > > Subject: Re: [Neo4j] neo4j-graph-collections
>> > > >
>> > > >
>> > > > As to the issue of n-dim doubles, it would be interesting to consider
>> > c

Re: [Neo4j] Problems building neo4j-rdf module

[Nikola Milikic]

Hi,

Thanks for the reply!

I'm not familiar with Thinkerpop, but I'll give it a try. My intention was
just to check out the performance neo4j would give when working with RDF
data, but to be honest, on a first glimpse, this looks over too complicated
for just reading some RDF data into a store.

Best,
Nikola


On Tue, Jun 28, 2011 at 3:13 PM, Mattias Persson
wrote:

> Another option could be to run it through the Tinkerpop stack and get
> access
> to a Sail with neo4j underneath that way. I think it's more up to date.
>
> https://github.com/tinkerpop/blueprints/wiki/Sail-Implementation
>
> 2011/6/28 Nikola Milikic 
>
> > Hi all,
> >
> > I wanted to try out neo4j-rdf library and found somewhere that there are
> no
> > official releases, but the library should be built from the source (
> > https://svn.neo4j.org/components/rdf/trunk). But when I checked out the
> > project, it reported dependency problems as some of the dependencies are
> > not
> > available. After I changed them to the ones available from the Maven
> > Central, then I got compilation errors.
> >
> > Did anyone face with the same problem and knows how to resolve this? Or,
> > better would be if somebody could provide me with builded jar.
> >
> > Thanks a lot for the help!
> >
> > Best,
> > Nikola Milikic
> >
> >
> > Nikola Milikic, BSc
> > Teaching Assistant
> > University of Belgrade, Serbia
> > 
> > email: nikola.mili...@gmail.com
> > URL:   nikola.milikic.info
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> >
>
>
>
> --
> Mattias Persson, [matt...@neotechnology.com]
> Hacker, Neo Technology
> www.neotechnology.com
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] infinitegraph vs neo4j vs orientdb

[venkat takumatla]

Sorry of that!  I uploaded to google docs. Here is the link

https://docs.google.com/leaf?id=0BzT4YMgj9xXsNGY4OGJiNzktYWM2Zi00YzU1LWE1NDAtOWIyMTEyNGU4OGUz&hl=en_US

Let me know if you have any problems in viewing it.

Venkat



On Wed, Jun 29, 2011 at 1:28 PM, Anders Nawroth wrote:

> Hi!
>
> I think the mailinglist removed the attached slides.
> Could you post a link instead?
>
> /anders
>
>
> On 06/29/2011 08:15 PM, venkat takumatla wrote:
>
>> I did some experiments on four graph database systems: neo4j, DEX,
>> infinitgraph, orientDB.
>> I think it might help you. I used very small graph  for evaluation when
>> compared to yours. You
>> can find the results from my experiment in 7th slide.  I ran pagerank for
>> ranking nodes and SCAN for clustering nodes.
>> Don't mind if something is wrong in it.
>>
>>
>>
>> Venkat
>>
>>
>>
>> On Wed, Jun 29, 2011 at 12:54 PM, Aliabbas Petiwala
>> **wrote:
>>
>>  greetings neo4j folks!
>>>
>>> we would really like to go for neo4j for our social networking website
>>> but
>>> we are still not convinced about the scalability and concurrency of neo4j
>>> considering that it may have to deal with billions of  peta bytes of
>>> data.
>>> a
>>> massive write load on master is predicted due to millions of users
>>> updating
>>> their status \ other information.
>>>
>>> infinitegraph.com  claims high scalability and distributed servers
>>> whereas
>>> neo4j constrains us on a single database and the  master seems to be the
>>> bottleneck in writes.
>>>
>>>  have any tests or simulations being performed on neo4j to gauge its
>>> efficiency and fault tolerance in large scale systems on the scale of
>>> facebook and twitter?
>>>
>>> orientdb is also promising since its open source but has only native
>>> support
>>> for graphs and has no spatial features which we require.
>>>
>>> hope neo4j folks convince us before we take a major decision of choosing
>>> the
>>> right graph db . we are also open to polyglot persistence involving a
>>> combination of neo4j, orientdb and cassandra is it wise to go for such a
>>> combination ?
>>>
>>> --
>>> Aliabbas Petiwala
>>> M.Tech CSE
>>> __**_
>>> Neo4j mailing list
>>> User@lists.neo4j.org
>>> https://lists.neo4j.org/**mailman/listinfo/user
>>>
>>>
>>
>>
>>
>>
>> __**_
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/**mailman/listinfo/user
>>
>


-- 
Thanking you,

Sincerely,
M.VenkataSwamy,
Graduate Research Assistant,
UALR
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] infinitegraph vs neo4j vs orientdb

[Anders Nawroth]

Hi!

I think the mailinglist removed the attached slides.
Could you post a link instead?

/anders

On 06/29/2011 08:15 PM, venkat takumatla wrote:
> I did some experiments on four graph database systems: neo4j, DEX,
> infinitgraph, orientDB.
> I think it might help you. I used very small graph  for evaluation when
> compared to yours. You
> can find the results from my experiment in 7th slide.  I ran pagerank for
> ranking nodes and SCAN for clustering nodes.
> Don't mind if something is wrong in it.
>
>
>
> Venkat
>
>
>
> On Wed, Jun 29, 2011 at 12:54 PM, Aliabbas 
> Petiwalawrote:
>
>> greetings neo4j folks!
>>
>> we would really like to go for neo4j for our social networking website but
>> we are still not convinced about the scalability and concurrency of neo4j
>> considering that it may have to deal with billions of  peta bytes of data.
>> a
>> massive write load on master is predicted due to millions of users updating
>> their status \ other information.
>>
>> infinitegraph.com  claims high scalability and distributed servers whereas
>> neo4j constrains us on a single database and the  master seems to be the
>> bottleneck in writes.
>>
>>   have any tests or simulations being performed on neo4j to gauge its
>> efficiency and fault tolerance in large scale systems on the scale of
>> facebook and twitter?
>>
>> orientdb is also promising since its open source but has only native
>> support
>> for graphs and has no spatial features which we require.
>>
>> hope neo4j folks convince us before we take a major decision of choosing
>> the
>> right graph db . we are also open to polyglot persistence involving a
>> combination of neo4j, orientdb and cassandra is it wise to go for such a
>> combination ?
>>
>> --
>> Aliabbas Petiwala
>> M.Tech CSE
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
>
>
>
>
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] infinitegraph vs neo4j vs orientdb

[venkat takumatla]

I did some experiments on four graph database systems: neo4j, DEX,
infinitgraph, orientDB.
I think it might help you. I used very small graph  for evaluation when
compared to yours. You
can find the results from my experiment in 7th slide.  I ran pagerank for
ranking nodes and SCAN for clustering nodes.
Don't mind if something is wrong in it.



Venkat



On Wed, Jun 29, 2011 at 12:54 PM, Aliabbas Petiwala wrote:

> greetings neo4j folks!
>
> we would really like to go for neo4j for our social networking website but
> we are still not convinced about the scalability and concurrency of neo4j
> considering that it may have to deal with billions of  peta bytes of data.
> a
> massive write load on master is predicted due to millions of users updating
> their status \ other information.
>
> infinitegraph.com  claims high scalability and distributed servers whereas
> neo4j constrains us on a single database and the  master seems to be the
> bottleneck in writes.
>
>  have any tests or simulations being performed on neo4j to gauge its
> efficiency and fault tolerance in large scale systems on the scale of
> facebook and twitter?
>
> orientdb is also promising since its open source but has only native
> support
> for graphs and has no spatial features which we require.
>
> hope neo4j folks convince us before we take a major decision of choosing
> the
> right graph db . we are also open to polyglot persistence involving a
> combination of neo4j, orientdb and cassandra is it wise to go for such a
> combination ?
>
> --
> Aliabbas Petiwala
> M.Tech CSE
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Thanking you,

Sincerely,
M.VenkataSwamy,
Graduate Research Assistant,
UALR
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] New to graph databases

[René Pickhardt]

Hey Jim,

I would like to know why you suggest to make relations more explicit. In the
redisign of our social network we are exchanging our old mysql db to neo4j.

One part of our datamodel is for User Nodes.

In order to make better friend recommendations on the longterm we try to
store as many relations between usernodes as possible. We hope to be able to
predict strong ties.

Especially we have the following relationships between user nodes (and some
others...)

   - UserUserFriendrequest
   - UserUserFriend
   - UserUserMessage
   - UserUserProfilevisited



our goal was to have all those relations timestampt
the UserUserMessage Relation should also contain 2 Key / Value pairs.

   - ("subject","any subject...")
   - ("text","any text")

To me it seems that in your usecase with a special Mail-Node we cannot so
quickly spot a connection between two users. What are the disadvanteges of
our way to model it?

Thanks for your feedback!

Best Regards René


2011/6/27 Jim Webber 

> Hi Stefan,
>
> These are good points, and I don't think we have yet reached a mature level
> of best practice as the relational folks have.  But I don't think graph
> modelling is too hard. I have a couple of rules of thumb:
>
> 1. Model entities as entities and use relationships to describe how those
> entities are related, don't be tempted to do anything more than basic facts
> - the aggregate of all those basic facts is sophisticated knowledge.
>
> 2. If you find your relationships have names like SENT_EMAIL_TO then you're
> missing an entity (in this case an email entity, naturally). So instead of
>
> Alice --SENT_EMAIL_TO-->Bob
> Alice--CC_EMAIL_TO-->Charles
>
> Use
>
> Alice-->SENT-->A specific email node
> Bob<--TO--A specific email node
> Charles<--CC--A specific email node
>
> That is, always look for places where you've hidden useful entities within
> relationships.
>
> FWIW Ian Robinson and I are doing the rounds doing a Neo4j tutorial that
> covers some of this kind of design material. Hop on one of those courses if
> you can. Otherwise the tutorial material is freely available here:
> https://github.com/jimwebber/neo4j-tutorial
>
> Jim
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
--
mobile: +49 (0)176 6433 2481

Skype: +49 (0)6131 / 4958926

Skype: rene.pickhardt

www.rene-pickhardt.de
 
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] graph db as ontology

[Aliabbas Petiwala]

btw i guess i saw somewhere that someone has imported dbpedia into neo4j

On Wed, Jun 29, 2011 at 11:35 PM, Aliabbas Petiwala wrote:

> please give your valuable suggestion privately !
>
>
> 2011/6/29 René Pickhardt 
>
>> Just in case someone intends to give a private answer. I would also be
>> very
>> interested in an answer to this question.
>>
>> 2011/6/29 Aliabbas Petiwala 
>>
>> > the graph db can itself be viewed as an ontology because rdf for example
>> is
>> > independent of syntax it just represents information model. so can  the
>> > petas teras of ontology classes in freebase, dbpedia etc  imported into
>> the
>> > graph db?. how well it would scale compared to infinitegraph and
>> orientdb
>> > --
>> > Aliabbas Petiwala
>> > M.Tech CSE
>> > ___
>> > Neo4j mailing list
>> > User@lists.neo4j.org
>> > https://lists.neo4j.org/mailman/listinfo/user
>> >
>>
>>
>>
>> --
>> --
>> mobile: +49 (0)176 6433 2481
>>
>> Skype: +49 (0)6131 / 4958926
>>
>> Skype: rene.pickhardt
>>
>> www.rene-pickhardt.de
>>  
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
>
>
>
> --
> Aliabbas Petiwala
> M.Tech CSE
>
>
>
>


-- 
Aliabbas Petiwala
M.Tech CSE
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] graph db as ontology

[Aliabbas Petiwala]

please give your valuable suggestion privately !

2011/6/29 René Pickhardt 

> Just in case someone intends to give a private answer. I would also be very
> interested in an answer to this question.
>
> 2011/6/29 Aliabbas Petiwala 
>
> > the graph db can itself be viewed as an ontology because rdf for example
> is
> > independent of syntax it just represents information model. so can  the
> > petas teras of ontology classes in freebase, dbpedia etc  imported into
> the
> > graph db?. how well it would scale compared to infinitegraph and orientdb
> > --
> > Aliabbas Petiwala
> > M.Tech CSE
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> >
>
>
>
> --
> --
> mobile: +49 (0)176 6433 2481
>
> Skype: +49 (0)6131 / 4958926
>
> Skype: rene.pickhardt
>
> www.rene-pickhardt.de
>  
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Aliabbas Petiwala
M.Tech CSE
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] graph db as ontology

[Marko Rodriguez]

Hi,

I have a project right now that uses Freebase in Neo4j and it works just fine. 

Also, for those interested in DBPedia (via and RDF representation) see Claudio 
Martella's work here:
http://blog.acaro.org/entry/dbpedia4neo

Enjoy,
Marko.

http://markorodriguez.com

On Jun 29, 2011, at 11:59 AM, René Pickhardt wrote:

> Just in case someone intends to give a private answer. I would also be very
> interested in an answer to this question.
> 
> 2011/6/29 Aliabbas Petiwala 
> 
>> the graph db can itself be viewed as an ontology because rdf for example is
>> independent of syntax it just represents information model. so can  the
>> petas teras of ontology classes in freebase, dbpedia etc  imported into the
>> graph db?. how well it would scale compared to infinitegraph and orientdb
>> --
>> Aliabbas Petiwala
>> M.Tech CSE
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>> 
> 
> 
> 
> -- 
> --
> mobile: +49 (0)176 6433 2481
> 
> Skype: +49 (0)6131 / 4958926
> 
> Skype: rene.pickhardt
> 
> www.rene-pickhardt.de
> 
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] graph db as ontology

[René Pickhardt]

Just in case someone intends to give a private answer. I would also be very
interested in an answer to this question.

2011/6/29 Aliabbas Petiwala 

> the graph db can itself be viewed as an ontology because rdf for example is
> independent of syntax it just represents information model. so can  the
> petas teras of ontology classes in freebase, dbpedia etc  imported into the
> graph db?. how well it would scale compared to infinitegraph and orientdb
> --
> Aliabbas Petiwala
> M.Tech CSE
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
--
mobile: +49 (0)176 6433 2481

Skype: +49 (0)6131 / 4958926

Skype: rene.pickhardt

www.rene-pickhardt.de
 
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] infinitegraph vs neo4j vs orientdb

[Aliabbas Petiwala]

greetings neo4j folks!

we would really like to go for neo4j for our social networking website but
we are still not convinced about the scalability and concurrency of neo4j
considering that it may have to deal with billions of  peta bytes of data. a
massive write load on master is predicted due to millions of users updating
their status \ other information.

infinitegraph.com  claims high scalability and distributed servers whereas
neo4j constrains us on a single database and the  master seems to be the
bottleneck in writes.

 have any tests or simulations being performed on neo4j to gauge its
efficiency and fault tolerance in large scale systems on the scale of
facebook and twitter?

orientdb is also promising since its open source but has only native support
for graphs and has no spatial features which we require.

hope neo4j folks convince us before we take a major decision of choosing the
right graph db . we are also open to polyglot persistence involving a
combination of neo4j, orientdb and cassandra is it wise to go for such a
combination ?

-- 
Aliabbas Petiwala
M.Tech CSE
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] graph db as ontology

[Aliabbas Petiwala]

the graph db can itself be viewed as an ontology because rdf for example is
independent of syntax it just represents information model. so can  the
petas teras of ontology classes in freebase, dbpedia etc  imported into the
graph db?. how well it would scale compared to infinitegraph and orientdb
-- 
Aliabbas Petiwala
M.Tech CSE
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] REST API & LuceneTimeline

[Matt Luongo]

If anyone else needs this functionality- we've thrown together a quick
plugin for indexing longs
at https://github.com/scholrly/neo4j-valuecontext-plugin.

--
Matt Luongo
Co-Founder, Scholr.ly



On Thu, Jun 16, 2011 at 10:12 AM, Mattias Persson  wrote:

> Yes, you're probably right in that instead POSTing with a payload of key,
> value and entity would provide the functionality needed here. It's a ticket
> at least and hopefully it will be fixed soon.
>
> 2011/6/15 Rick Bullotta 
>
> > Depends I would think on how you are putting/posting the data.  If via
> XML
> > or URL parameters, I can't see how Neo would know whether it was a string
> or
> > a number, but if via JSON you should be able to get it in there properly.
> >
> > Perhaps the REST API should support passing content via either the URL or
> > via a POST'ed payload.  That's what we do with our internally created
> REST
> > API today (support URL parameters, XML, or JSON for all calls, with the
> URI
> > defining the "intent" or the "method" and query parameters XML/JSON
> defining
> > the "parameters").
> >
> > I know the REST API has some "soak time" already, but I would seriously
> > consider redesigning parts of it to treat some of the parameters
> differently
> > when the Content-Type is JSON (e.g. pass them in the payload, not the
> URI,
> > as with the REST API that lets you create a node w/properties).  Let's
> take
> > indexing for example.  The approach I'm proposing would allow an atomic
> call
> > to index multiple fields, rather than one at a time, as with the current
> > approach, and it would allow more flexible data types.  Indexing all the
> > fields at once is, to me, an essential capability to ensure the semantic
> > integrity of the graph.
> >
> > An example is:
> >
> > POST http://localhost:7474/db/data/index/node/favorites
> >
> > POST Content :
> >
> > {
> >  "fields" : [
> >{
> >  "key" : "key1"
> >  "value" : 12345
> >},
> >{
> >  "key" : "key2"
> >  "value" : "ABC"
> >},
> >{
> >  "key" : "key3"
> >  "value" : [ "Dogs", "Cats", "Sheep" ]
> >}
> >  ]
> > }
> >
> > *Accept: application/json
> > *Content-Type: application/json
> >
> >
> > -Original Message-
> > From: Peter Neubauer [mailto:neubauer.pe...@gmail.com]
> > Sent: Wednesday, June 15, 2011 10:30 AM
> > To: Matt Luongo
> > Cc: Neo4j user discussions; Rick Bullotta
> > Subject: Re: [Neo4j] REST API & LuceneTimeline
> >
> > Matt,
> > inserting by other than String in
> >
> >
> http://docs.neo4j.org/chunked/snapshot/rest-api-indexes.html#rest-api-add-node-to-index
> > is not supported. A shortcoming. This is probably what your plugin
> > should be doing in that case. Will add that as a ticket to be tracked.
> >
> >
> >
> http://neo4jdb.lighthouseapp.com/projects/77609-neo4j-community/tickets/9-support-inserting-index-values-other-than-string-via-rest
> >
> > -peter
> >
> > On Wed, Jun 15, 2011 at 4:27 PM, Matt Luongo  wrote:
> > > It does- awesome, I didn't realize the query syntax would work for
> > > numeric fields, as well. Now I just need to figure out how to insert
> > > into a numeric field via rest.
> > >
> > > --
> > > Matt Luongo
> > > Co-Founder, Scholr.ly
> > >
> > >
> > >
> > > On Wed, Jun 15, 2011 at 10:24 AM, Rick Bullotta
> > >  wrote:
> > >> Hi, Matt.
> > >>
> > >> We don't use the REST API (we use Neo4J in an embedded mode), so I
> can't
> > be of much help there.  If the REST API supports Lucene query syntax, you
> > can use something like:
> > >>
> > >> timestamp : [1 to 2]
> > >>
> > >> You'd need to do the Date <-> UTC milliseconds conversion on the front
> > end, I'd think.
> > >>
> > >> Rick
> > >>
> > >> -Original Message-
> > >> From: user-boun...@lists.neo4j.org [mailto:
> user-boun...@lists.neo4j.org]
> > On Behalf Of Matt Luongo
> > >> Sent: Wednesday, June 15, 2011 10:03 AM
> > >> To: Peter Neubauer
> > >> Cc: user@lists.neo4j.org
> > >> Subject: Re: [Neo4j] REST API & LuceneTimeline
> > >>
> > >> Peter,
> > >>
> > >> Kind of. I see how I could do that server-side, but not how to insert
> > >> elements into the index numerically (with
> > >> ValueContext(val).indexNumeric()) or query by range (
> > >> .query(QueryContext.numericRange() ) via REST. Is this something
> > >> that will require our writing a plugin to support, or is there
> > >> currently some way to index and query numerically via the REST API?
> > >>
> > >> --
> > >> Matt Luongo
> > >> Co-Founder, Scholr.ly
> > >>
> > >>
> > >>
> > >> On Wed, Jun 15, 2011 at 9:25 AM, Peter Neubauer
> > >>  wrote:
> > >>> Yeah,
> > >>> just checked with Mattias. There is no such index configuration, so
> > >>> this does not work. I think you should use the numeric field in a
> > >>> normal index for this, just like Rick points out.
> > >>>
> > >>> Does that make sense?
> > >>>
> > >>> /peter
> > >>>
> > >>> On Wed, Jun 15, 2011 at 3:03 PM, Matt Luongo  wro

Re: [Neo4j] traversing densely populated nodes

[Agelos Pikoulas]

My problem pattern is exactly the same as Niels's :

A dense-node has millions of relations of a certain direction & type,
and only a few (sparse) relations of a different direction and type.
The traversing is usually following only those sparse relationships on those
dense-nodes.

Now, even when traversing on these sparse relations, neo4j becomes extremely
slow
on a certainly non linear Order (the big cs O).

Some tests I run (email me if u want the code) reveal that even the number
of those dense-nodes in the database greatly influences the results.

I just reported to Michael the runs with the latest M05 snapshot, which are
not very positive...
I have suggested an (auto) indexing of relationship types / direction that
is used by traversing frameworks,
but I ain't no graphdb-engine expert :-(

A'


Message: 5
> Date: Wed, 29 Jun 2011 18:19:10 +0200
> From: Niels Hoogeveen 
> Subject: Re: [Neo4j] traversing densely populated nodes
> To: 
> Message-ID: 
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Michael,
>
>
>
> The issue I am refering to does not pertain to traversing many relations at
> once
>
> but the impact many relationship of one type have on relationships
>
> of another type on the same node.
>
>
>
> Example:
>
>
>
> A topic class has 2 million outgoing relationships of type "HAS_INSTANCE"
> and
>
> has 3 outgoing relationships of type "SUB_CLASS_OF".
>
>
>
> Fetching the 3 relations of type "SUB_CLASS_OF" takes very long,
>
> I presume due to the presence of the 2 million other relationships.
>
>
>
> I have no need to ever fetch the "HAS_INSTANCE" relationships from
>
> the topic node. That relation is always traversed from the other direction.
>
>
>
> I do want to know the class of a topic instance, leading to he topic class,
>
> but have no real interest ever to traverse all topic instance from  the
> topic
>
> class (at least not directly.. i do want to know the most recent addition,
>
> and that's what I use the timeline index for).
>
>
>
> Niels
>
>
> > From: michael.hun...@neotechnology.com
> > Date: Wed, 29 Jun 2011 17:50:08 +0200
> > To: user@lists.neo4j.org
> > Subject: Re: [Neo4j] traversing densely populated nodes
> >
> > I think this is the same problem that Angelos is facing, we are currently
> evaluating options to improve the performance on those highly connected
> supernodes.
> >
> > A traditional option is really to split them into group or even kind of
> shard their relationships to a second layer.
> >
> > We're looking into storage improvement options as well as modifications
> to retrieval of that many relationships at once.
> >
> > Cheers
> >
> > Michael
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Neo4j proof of efficiency

[Ian Bussières]

Yes that's what I am looking for. If there are any others that come to mind, 
please keep them coming :)

Emailed from my iPhone

On 2011-06-28, at 06:24, Johan Svensson  wrote:

> Hi,
> 
> This may be of interest http://arxiv.org/abs/1004.1001 (The Graph
> Traversal Pattern) and
> http://markorodriguez.com/2011/02/18/mysql-vs-neo4j-on-a-large-scale-graph-traversal/
> 
> Regards,
> Johan
> 
> 2011/6/27 Ian Bussières :
>> Hello,
>> 
>> I am using neo4j in a school project. I was wondering if anyone could point
>> me to a scientific paper or proof of concept - something with actual data -
>> that would be useful to build a document that would prove graph databases to
>> be more suited (performance, scalability and efficiency) to a social
>> network-like application. I'm interested in any benchmarks or design keys of
>> any sort, books, whatever. I've searched a lot but have failed to find
>> enough relevant sources of information.
>> 
>> Thanks ahead of time,
>> 
>> Ian.
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] traversing densely populated nodes

[Niels Hoogeveen]

Michael,

 

The issue I am refering to does not pertain to traversing many relations at 
once 

but the impact many relationship of one type have on relationships 

of another type on the same node.

 

Example:

 

A topic class has 2 million outgoing relationships of type "HAS_INSTANCE" and 

has 3 outgoing relationships of type "SUB_CLASS_OF".

 

Fetching the 3 relations of type "SUB_CLASS_OF" takes very long,

I presume due to the presence of the 2 million other relationships.

 

I have no need to ever fetch the "HAS_INSTANCE" relationships from

the topic node. That relation is always traversed from the other direction.

 

I do want to know the class of a topic instance, leading to he topic class,

but have no real interest ever to traverse all topic instance from  the topic 

class (at least not directly.. i do want to know the most recent addition,

and that's what I use the timeline index for).

 

Niels
 

> From: michael.hun...@neotechnology.com
> Date: Wed, 29 Jun 2011 17:50:08 +0200
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] traversing densely populated nodes
> 
> I think this is the same problem that Angelos is facing, we are currently 
> evaluating options to improve the performance on those highly connected 
> supernodes.
> 
> A traditional option is really to split them into group or even kind of shard 
> their relationships to a second layer.
> 
> We're looking into storage improvement options as well as modifications to 
> retrieval of that many relationships at once.
> 
> Cheers
> 
> Michael
> 
> Am 29.06.2011 um 17:13 schrieb Niels Hoogeveen:
> 
> > 
> > I achieve more or less the same result placing the relationships in the 
> > Timeline index, which distributes the relationships over many nodes. 
> > There are workarounds for this issue, but I would really like to see a more 
> > transparent solution which doesn't require special interventions for 
> > special cases. 
> > I don't know the inner details of the relationship store and wonder if it 
> > is possible to partition relationships per node per relationship type per 
> > direction. It makes intuitive sense if there are many relationships of the 
> > same type and same direction that traversing those takes a lot of time. It 
> > doesn't make intuitive sense that relationships with another type and/or 
> > direction take a lot of time too.
> > Niels
> > 
> >> Date: Wed, 29 Jun 2011 16:36:57 +0200
> >> From: ntausc...@gmail.com
> >> To: user@lists.neo4j.org
> >> Subject: Re: [Neo4j] traversing densely populated nodes
> >> 
> >> I focused the same problem. Nodes with a lot of relationships are very
> >> difficult (needs a lot of time) to be traversed. I solved the problem by
> >> grouping the relationships using additional nodes. The dense node then
> >> has only a few relationships to different 'group' nodes. Each 'group'
> >> node then has again many relationships to other nodes.
> >> 
> >> Although this helps, it is a very ugly solution.
> >> 
> >> Best regards
> >> 
> >> Norbert Tausch
> >> 
> >> 
> >> Am 29.06.2011 16:07, schrieb Niels Hoogeveen:
> >>> Recently I have worked on loading the content of DbPedia into my database 
> >>> and run into a performance issue.
> >>> My application has a meta-layer; inspired by the meta model component, 
> >>> but rewritten in Scala.
> >>> All DbPedia resources are said to be an instance of "topic", 
> >>> creating a relationship from that resource node to the node that 
> >>> describes the topic class.
> >>> This makes the "topic class" node of course densely populated.
> >>> The "topic class" node has relationships other than "HAS_INSTANCE", 
> >>> for example "SUB_CLASS_OF", which states that the "topic class" node is a 
> >>> subclass of "typable". 
> >>> When trying to retrieve the "SUB_CLASS_OF" relationships of the "topic 
> >>> class" node performance degrades enormously. 
> >>> 
> >>> It looks (please correct me if I am wrong in my assumption) as if all 
> >>> relationships are being scanned 
> >>> to filter out the "SUB_CLASS_OF" relationships (of which there are very 
> >>> few, especially compared to the "HAS_INSTANCE" relationship)
> >>> I ended up placing all "HAS_INSTANCE" into the Timeline index from 
> >>> Neo4j-graph-collections for two reasons,it's nice to know when a resource 
> >>> became an instance of a class (bonus), and to make sure that not a single 
> >>> nodebecomes heavily populated.
> >>> So far so good, but delving deeper into the Timeline index, I notice that 
> >>> the relationship between an entry nodeand the root of the tree is 
> >>> partially established by the use of a property on "entry node" which 
> >>> names the timeline index.
> >>> The simplest way to establish the relationship between an "entry node" 
> >>> and the tree root is by means of a Lucene index lookup.
> >>> This is of course not a very fastest solution and actually would mean the 
> >>> same as adding a property to the "resource node", listing the classes a 
> >>> resource 

Re: [Neo4j] traversing densely populated nodes

[Michael Hunger]

I think this is the same problem that Angelos is facing, we are currently 
evaluating options to improve the performance on those highly connected 
supernodes.

A traditional option is really to split them into group or even kind of shard 
their relationships to a second layer.

We're looking into storage improvement options as well as modifications to 
retrieval of that many relationships at once.

Cheers

Michael

Am 29.06.2011 um 17:13 schrieb Niels Hoogeveen:

> 
> I achieve more or less the same result placing the relationships in the 
> Timeline index, which distributes the relationships over many nodes. 
> There are workarounds for this issue, but I would really like to see a more 
> transparent solution which doesn't require special interventions for special 
> cases. 
> I don't know the inner details of the relationship store and wonder if it is 
> possible to partition relationships per node per relationship type per 
> direction. It makes intuitive sense if there are many relationships of the 
> same type and same direction that traversing those takes a lot of time. It 
> doesn't make intuitive sense that relationships with another type and/or 
> direction take a lot of time too.
> Niels
> 
>> Date: Wed, 29 Jun 2011 16:36:57 +0200
>> From: ntausc...@gmail.com
>> To: user@lists.neo4j.org
>> Subject: Re: [Neo4j] traversing densely populated nodes
>> 
>> I focused the same problem. Nodes with a lot of relationships are very
>> difficult (needs a lot of time) to be traversed. I solved the problem by
>> grouping the relationships using additional nodes. The dense node then
>> has only a few relationships to different 'group' nodes. Each 'group'
>> node then has again many relationships to other nodes.
>> 
>> Although this helps, it is a very ugly solution.
>> 
>> Best regards
>> 
>> Norbert Tausch
>> 
>> 
>> Am 29.06.2011 16:07, schrieb Niels Hoogeveen:
>>> Recently I have worked on loading the content of DbPedia into my database 
>>> and run into a performance issue.
>>> My application has a meta-layer; inspired by the meta model component, but 
>>> rewritten in Scala.
>>> All DbPedia resources are said to be an instance of "topic", 
>>> creating a relationship from that resource node to the node that describes 
>>> the topic class.
>>> This makes the "topic class" node of course densely populated.
>>> The "topic class" node has relationships other than "HAS_INSTANCE", 
>>> for example "SUB_CLASS_OF", which states that the "topic class" node is a 
>>> subclass of "typable". 
>>> When trying to retrieve the "SUB_CLASS_OF" relationships of the "topic 
>>> class" node performance degrades enormously. 
>>> 
>>> It looks (please correct me if I am wrong in my assumption) as if all 
>>> relationships are being scanned 
>>> to filter out the "SUB_CLASS_OF" relationships (of which there are very 
>>> few, especially compared to the "HAS_INSTANCE" relationship)
>>> I ended up placing all "HAS_INSTANCE" into the Timeline index from 
>>> Neo4j-graph-collections for two reasons,it's nice to know when a resource 
>>> became an instance of a class (bonus), and to make sure that not a single 
>>> nodebecomes heavily populated.
>>> So far so good, but delving deeper into the Timeline index, I notice that 
>>> the relationship between an entry nodeand the root of the tree is partially 
>>> established by the use of a property on "entry node" which names the 
>>> timeline index.
>>> The simplest way to establish the relationship between an "entry node" and 
>>> the tree root is by means of a Lucene index lookup.
>>> This is of course not a very fastest solution and actually would mean the 
>>> same as adding a property to the "resource node", listing the classes a 
>>> resource is an instance of.
>>> Adding a relationship from "entry node" to "tree root" in the Timeline 
>>> component would create yet another densely populated nodein the database 
>>> (in this case the tree root). 
>>> Is there a way out of this situation? 
>>> Would it be possible to partition the relationships in the database per 
>>> relationship type per direction, so densely populated nodescan get 
>>> traversed fast for those relationships types that are sparsely populated?
>>> Niels
>>>   
>>> ___
>>> Neo4j mailing list
>>> User@lists.neo4j.org
>>> https://lists.neo4j.org/mailman/listinfo/user
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
> 
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Regarding developing an application with Neo4j

[Michael Hunger]

Sanju,

there is also a wiki page with directions for different visualization options 
for webapps.

http://wiki.neo4j.org/content/Visualization_options_for_graphs

Michael

Am 29.06.2011 um 13:58 schrieb Stefan Zapf:

> Hi Sanju,
> 
> I'm just a newbie to neo4j, but maybe it's helpful to think about the tasks 
> you are facing. There are general and neo4j specific tasks embedded in your 
> questions:
> 
> 1. Retrieve data from the neo4j graphs (specific neo4j question)
> 2. Display the data to the user  (general question on Web-app design)
> 
> Specifically, you need to retrieve the data stored in your neo4j graph. There 
> are two ways to do this:
> 
> 1. Embed the database in your own program and access the "directly"
> 2. Retrieve the data indirectly using neo4j's REST API (standalone server)
> 2.1. Use your own servside program that speaks with your client (Java 
> Servlets,  ...)
> 2.2. Access the REST API directly from your client
> 
> You can find a pretty good tutorials on both 1 and 2, here: 
> http://wiki.neo4j.org/content/Getting_Started_Guide . Imagine you create an 
> online address book. Then you might decide for 1 and write a Java program 
> running on your server and publishes its own REST API. Let's assume you can 
> retrieve all addresses by GETting /addressbook/contacts . Then your java 
> program retrieves all addresses stored in neo4j and sends the requested 
> addressses to any client which GETs /addressbook/contacts .
> 
> Once you've decided on an embedded solution or standalone server, you will 
> need to decide on how to display the data. There are two basic ways that you 
> can access the data via a simple webbrowser: vendor specific solutions that 
> are downloaded by your browser and run in your browser (Java Applets, Active 
> X, Flash) or by making use of an AJAX framework i.e. using your Browsers 
> in-built functions (Javascript, HTML, css). These questions are probably 
> better suited for a specific forum on the given technology. For sake of our 
> previous example, you might use the JQuery Javascript Library to access the 
> contact stored /addressbok/contacts and display them to your users.
> 
> However, if your goal is actually an Neoclipse-like application. You may 
> simply point your browser to host:7474 , the neo4j webadmin has a nice 
> visualization tool.
> 
> Best luck
> Stefan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Am 29.06.2011 13:19, schrieb sanjana sanju:
>> Hello Neo4j Team,
>> 
>> I am new to neo4j. I have gone through the documentation, Its really
>> awesome. You people have done excellent work.
>> 
>> I have developed a small or sample graph based application in Java which
>> contains a data (users) who are near at some place. Its working
>> perfectly. For visualization I used stand alone application (Neoclipse). It
>> is also working fine and showing perfectly what I want.
>> 
>> Now I want to re-design my application like as a web application, that means
>> I want to see my database as a web content (Visualization for a web-user
>> that how that user has connected with others graphically) same as like
>> the functionality of neoclipse.
>> 
>> I am technically not that sound (experience). So can any one please suggest
>> me some ideas or tools to design such application.
>> 
>> Can I use neoclipse as a web application or as a server-side application? If
>> so help me out from this... to design a web application.
>> 
>> Awaiting for your valuable suggestions.
>> 
>> Regards,
>> Sanju.
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
> 
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] traversing densely populated nodes

[Marko Rodriguez]

Hi,

In situations where there is a high degree vertex [ 
http://en.wikipedia.org/wiki/Degree_(graph_theory) ], I tend to do graph 
sampling. That is, I do not traverse everything outgoing/incoming from the 
vertex. For example, in Gremlin:

rand = new Random();
highDegreeVertex.outE{rand.nextBoolean()}.inV

In the above traversal, probabilistically, only 50% of the edges out of 
highDegreeVertex are traversed. If your edges are weighted, then you can do a 
biased coin toss to only sample those paths that are heavily weighted.

highDegreeVertex.outE{rand.nextDouble() < it.weight}.inV

If the edge weight is in [0,1] and larger weight is a "stronger" connection, 
then this will ensure that you have a higher probability of taking strong 
edges, while still having the potential to take low probability edges --- thus, 
not so "cut and dry" as a clip-based filter. E.g.

highDegreeVertex.outE{it.weight > 0.5}.inV

Finally, sampling assumes a query/traversal situation that is non-deterministic 
and as such, not a "get me the data if it exists"-situation. For me, most of my 
query/traversal situations are based on local/global-ranks where approximations 
are acceptable and necessary for real-time speed. I see this as a big 
distinguisher amongst graph vs. other database models. In the world of graphs, 
thinking of your data like "a neural network (graph) of action potentials 
(traversals)" leads to novel models of data retrieval, data organization, and 
relaxes deterministic constraints allowing for increased speed.

Thanks,
Marko.

http://markorodriguez.com

On Jun 29, 2011, at 8:36 AM, Norbert Tausch wrote:

> I focused the same problem. Nodes with a lot of relationships are very
> difficult (needs a lot of time) to be traversed. I solved the problem by
> grouping the relationships using additional nodes. The dense node then
> has only a few relationships to different 'group' nodes. Each 'group'
> node then has again many relationships to other nodes.
> 
> Although this helps, it is a very ugly solution.
> 
> Best regards
> 
> Norbert Tausch
> 
> 
> Am 29.06.2011 16:07, schrieb Niels Hoogeveen:
>> Recently I have worked on loading the content of DbPedia into my database 
>> and run into a performance issue.
>> My application has a meta-layer; inspired by the meta model component, but 
>> rewritten in Scala.
>> All DbPedia resources are said to be an instance of "topic", 
>> creating a relationship from that resource node to the node that describes 
>> the topic class.
>> This makes the "topic class" node of course densely populated.
>> The "topic class" node has relationships other than "HAS_INSTANCE", 
>> for example "SUB_CLASS_OF", which states that the "topic class" node is a 
>> subclass of "typable". 
>> When trying to retrieve the "SUB_CLASS_OF" relationships of the "topic 
>> class" node performance degrades enormously. 
>> 
>> It looks (please correct me if I am wrong in my assumption) as if all 
>> relationships are being scanned 
>> to filter out the "SUB_CLASS_OF" relationships (of which there are very few, 
>> especially compared to the "HAS_INSTANCE" relationship)
>> I ended up placing all "HAS_INSTANCE" into the Timeline index from 
>> Neo4j-graph-collections for two reasons,it's nice to know when a resource 
>> became an instance of a class (bonus), and to make sure that not a single 
>> nodebecomes heavily populated.
>> So far so good, but delving deeper into the Timeline index, I notice that 
>> the relationship between an entry nodeand the root of the tree is partially 
>> established by the use of a property on "entry node" which names the 
>> timeline index.
>> The simplest way to establish the relationship between an "entry node" and 
>> the tree root is by means of a Lucene index lookup.
>> This is of course not a very fastest solution and actually would mean the 
>> same as adding a property to the "resource node", listing the classes a 
>> resource is an instance of.
>> Adding a relationship from "entry node" to "tree root" in the Timeline 
>> component would create yet another densely populated nodein the database (in 
>> this case the tree root). 
>> Is there a way out of this situation? 
>> Would it be possible to partition the relationships in the database per 
>> relationship type per direction, so densely populated nodescan get traversed 
>> fast for those relationships types that are sparsely populated?
>> Niels
>>
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] traversing densely populated nodes

[Niels Hoogeveen]

I achieve more or less the same result placing the relationships in the 
Timeline index, which distributes the relationships over many nodes. 
There are workarounds for this issue, but I would really like to see a more 
transparent solution which doesn't require special interventions for special 
cases. 
I don't know the inner details of the relationship store and wonder if it is 
possible to partition relationships per node per relationship type per 
direction. It makes intuitive sense if there are many relationships of the same 
type and same direction that traversing those takes a lot of time. It doesn't 
make intuitive sense that relationships with another type and/or direction take 
a lot of time too.
Niels

> Date: Wed, 29 Jun 2011 16:36:57 +0200
> From: ntausc...@gmail.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] traversing densely populated nodes
> 
> I focused the same problem. Nodes with a lot of relationships are very
> difficult (needs a lot of time) to be traversed. I solved the problem by
> grouping the relationships using additional nodes. The dense node then
> has only a few relationships to different 'group' nodes. Each 'group'
> node then has again many relationships to other nodes.
> 
> Although this helps, it is a very ugly solution.
> 
> Best regards
> 
> Norbert Tausch
> 
> 
> Am 29.06.2011 16:07, schrieb Niels Hoogeveen:
> > Recently I have worked on loading the content of DbPedia into my database 
> > and run into a performance issue.
> > My application has a meta-layer; inspired by the meta model component, but 
> > rewritten in Scala.
> > All DbPedia resources are said to be an instance of "topic", 
> > creating a relationship from that resource node to the node that describes 
> > the topic class.
> > This makes the "topic class" node of course densely populated.
> > The "topic class" node has relationships other than "HAS_INSTANCE", 
> > for example "SUB_CLASS_OF", which states that the "topic class" node is a 
> > subclass of "typable". 
> > When trying to retrieve the "SUB_CLASS_OF" relationships of the "topic 
> > class" node performance degrades enormously. 
> >
> > It looks (please correct me if I am wrong in my assumption) as if all 
> > relationships are being scanned 
> > to filter out the "SUB_CLASS_OF" relationships (of which there are very 
> > few, especially compared to the "HAS_INSTANCE" relationship)
> > I ended up placing all "HAS_INSTANCE" into the Timeline index from 
> > Neo4j-graph-collections for two reasons,it's nice to know when a resource 
> > became an instance of a class (bonus), and to make sure that not a single 
> > nodebecomes heavily populated.
> > So far so good, but delving deeper into the Timeline index, I notice that 
> > the relationship between an entry nodeand the root of the tree is partially 
> > established by the use of a property on "entry node" which names the 
> > timeline index.
> > The simplest way to establish the relationship between an "entry node" and 
> > the tree root is by means of a Lucene index lookup.
> > This is of course not a very fastest solution and actually would mean the 
> > same as adding a property to the "resource node", listing the classes a 
> > resource is an instance of.
> > Adding a relationship from "entry node" to "tree root" in the Timeline 
> > component would create yet another densely populated nodein the database 
> > (in this case the tree root). 
> > Is there a way out of this situation? 
> > Would it be possible to partition the relationships in the database per 
> > relationship type per direction, so densely populated nodescan get 
> > traversed fast for those relationships types that are sparsely populated?
> > Niels
> >   
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
  
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] cassandra + neo4j graph

[Jim Webber]

Hi Aliabbas,

Each node gets a URI by default if you're using the REST API.

I have no words of wisdom on the utility of OWL/RDF for your case, but if you 
need to call out to an external ontology, it sounds likely you should embrace 
the semweb.

Jim
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] traversing densely populated nodes

[Norbert Tausch]

I focused the same problem. Nodes with a lot of relationships are very
difficult (needs a lot of time) to be traversed. I solved the problem by
grouping the relationships using additional nodes. The dense node then
has only a few relationships to different 'group' nodes. Each 'group'
node then has again many relationships to other nodes.

Although this helps, it is a very ugly solution.

Best regards

Norbert Tausch


Am 29.06.2011 16:07, schrieb Niels Hoogeveen:
> Recently I have worked on loading the content of DbPedia into my database and 
> run into a performance issue.
> My application has a meta-layer; inspired by the meta model component, but 
> rewritten in Scala.
> All DbPedia resources are said to be an instance of "topic", 
> creating a relationship from that resource node to the node that describes 
> the topic class.
> This makes the "topic class" node of course densely populated.
> The "topic class" node has relationships other than "HAS_INSTANCE", 
> for example "SUB_CLASS_OF", which states that the "topic class" node is a 
> subclass of "typable". 
> When trying to retrieve the "SUB_CLASS_OF" relationships of the "topic class" 
> node performance degrades enormously. 
>
> It looks (please correct me if I am wrong in my assumption) as if all 
> relationships are being scanned 
> to filter out the "SUB_CLASS_OF" relationships (of which there are very few, 
> especially compared to the "HAS_INSTANCE" relationship)
> I ended up placing all "HAS_INSTANCE" into the Timeline index from 
> Neo4j-graph-collections for two reasons,it's nice to know when a resource 
> became an instance of a class (bonus), and to make sure that not a single 
> nodebecomes heavily populated.
> So far so good, but delving deeper into the Timeline index, I notice that the 
> relationship between an entry nodeand the root of the tree is partially 
> established by the use of a property on "entry node" which names the timeline 
> index.
> The simplest way to establish the relationship between an "entry node" and 
> the tree root is by means of a Lucene index lookup.
> This is of course not a very fastest solution and actually would mean the 
> same as adding a property to the "resource node", listing the classes a 
> resource is an instance of.
> Adding a relationship from "entry node" to "tree root" in the Timeline 
> component would create yet another densely populated nodein the database (in 
> this case the tree root). 
> Is there a way out of this situation? 
> Would it be possible to partition the relationships in the database per 
> relationship type per direction, so densely populated nodescan get traversed 
> fast for those relationships types that are sparsely populated?
> Niels
> 
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] BatchInserter with Lucene Index

[Dario Rexin]

Hi all,

Recently i tried import a huge dataset into neo using the BatchInserter. I also 
used the BatchInserterIndex. The import itself went very well and i was able to 
read from the graph, but when i tried to insert something i always got an error 
saying that no new transaction could be created. Here’s how I used the index:

// provider is a LuceneBatchInserterIndexProvider
BatchInserterIndex urnIndex = provider.nodeIndex("urn", MapUtil.stringMap( 
"type", "exact" ));

for (Map.Entry entry : nodes.entrySet()) {
  Map props = MapUtil.map("urn", entry.getKey());
  urnIndex.add(entry.getValue(), props);
}

I also called shutdown() on the provider and the BatchInserter afterwards. Is 
there anything i am missing?


Cheers,

Dario
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] neo4j-graph-collections

[Niels Hoogeveen]

Craig,
Would it be possible to merge your work on Amanzi with the work the Neo team 
has done on the Btree component that is now in neo4j-graph-collections, so we 
can eventually have one implementation that meets a broad variety of needs?
Niels

> Date: Wed, 29 Jun 2011 15:34:47 +0200
> From: cr...@amanzi.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> I have previously used two solutions to deal with multiple types in btrees:
> 
>- My first index in 2009 was a btree-like n-dim index using generics to
>support int[], long[], float[] and double[] (no strings). I used this for
>TimeLine (long[1]) and Location (double[2]). The knowledge about what type
>was used was in the code for constructing the index (whether a new index or
>accessing an existing index in the graph).
>- In December I started my amanzi-index (on
> github)
>that is also btree-like, n-dimensional. But this time it can index multiple
>types in the same tree (so a float, int and string in the same tree, 
> instead
>of being forced to have all properties of the same type). It is a re-write
>of the previous index to support Strings, and mixed types. This time it 
> does
>save the type information in meta-data at the tree root.
> 
> The idea of using a 'comparator' class for the types is similar, but simpler
> than the idea I implemented for amanzi-index, where I have mapper classes
> that describe not only how to compare types, but also how to map from values
> to index keys and back. This includes (to some extent) the concept of the
> lucene analyser, since the mapper can decide on custom distribution of, for
> example, strings and category indexes.
> 
> For both of these indexes, you configure the index up front, and then only
> call index.add(node) to index a node. This will fit in well with the new
> auto-indexing ideas in neo4j.
> 
> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
> wrote:
> 
> >
> >
> >
> >
> >
> > At this moment Btree only supports the primitive datatype long, while Rtree
> > only supports the datatype double. For Btree it makes sense to at least
> > support strings, floats, doubles and ints too. Use cases for these data
> > types are pretty obvious and are Btree backed in (almost) every RDBMS
> > product around.I think the best solution would be to create Comparator
> > objects wrapping these primitive data types and store the class name of the
> > comparator in root of the index tree. This allows users to create their own
> > comparators for datatypes not covered yet. It would make sense people would
> > want to store BigInt and BigDecimal objects in a Btree too, others may want
> > to store dates (instead of datetime), fractions, complex numbers or even
> > more exotic data types.
> > Niels
> > > From: sxk1...@hotmail.com
> > > To: user@lists.neo4j.org
> > > Date: Tue, 28 Jun 2011 22:43:24 -0700
> > > Subject: Re: [Neo4j] neo4j-graph-collections
> > >
> > >
> > > I've read through this thread in more detail and have a few thoughts,
> > when you talk about type I am assuming that you are referring to an
> > interface that both (Btree,Rtree) can implement, for the data types I'd like
> > to understand the use cases first before implementing the different data
> > types, maybe we could store types of Object instead of Long or Double and
> > implement comparators in a more meaningful fashion.   Also I was wondering
> > if unit tests would need to be extracted out of the spatial component and
> > embedded inside the graph-collections component as well or whether we'd
> > potentially need to write brand new unit tests as well.
> > > Craig as I mentioned I'd love to help, let me know if it would be
> > possible to fork a repo or to talk in more detail this week.
> > > Regards
> > >
> > > > From: pd_aficion...@hotmail.com
> > > > To: user@lists.neo4j.org
> > > > Date: Wed, 29 Jun 2011 01:35:43 +0200
> > > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > >
> > > >
> > > > As to the issue of n-dim doubles, it would be interesting to consider
> > creating a set of classes of type Orderable (supporting <, <=, >, >=
> > operations), this we can use in both Rtree and Btree. Right now Btree only
> > supports datatype Long. This should also become more generic. A first step
> > we can take is at least wrap the common datatypes in Orderable classes.
> > > > Niels
> > > >
> > > > > Date: Wed, 29 Jun 2011 00:32:15 +0200
> > > > > From: cr...@amanzi.com
> > > > > To: user@lists.neo4j.org
> > > > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > > >
> > > > > The RTree in principle should be generalizable, but the current
> > > > > implementation in neo4j-spatial does make a few assumptions specific
> > to
> > > > > spatial data, and makes use of spatial envelopes for the tree node
> > bounding
> > > > > boxes. It is also specific to 2D. We could make a few improvements
> > first,
> > > > > like generalizi

[Neo4j] traversing densely populated nodes

[Niels Hoogeveen]

Recently I have worked on loading the content of DbPedia into my database and 
run into a performance issue.
My application has a meta-layer; inspired by the meta model component, but 
rewritten in Scala.
All DbPedia resources are said to be an instance of "topic", 
creating a relationship from that resource node to the node that describes the 
topic class.
This makes the "topic class" node of course densely populated.
The "topic class" node has relationships other than "HAS_INSTANCE", 
for example "SUB_CLASS_OF", which states that the "topic class" node is a 
subclass of "typable". 
When trying to retrieve the "SUB_CLASS_OF" relationships of the "topic class" 
node performance degrades enormously. 

It looks (please correct me if I am wrong in my assumption) as if all 
relationships are being scanned 
to filter out the "SUB_CLASS_OF" relationships (of which there are very few, 
especially compared to the "HAS_INSTANCE" relationship)
I ended up placing all "HAS_INSTANCE" into the Timeline index from 
Neo4j-graph-collections for two reasons,it's nice to know when a resource 
became an instance of a class (bonus), and to make sure that not a single 
nodebecomes heavily populated.
So far so good, but delving deeper into the Timeline index, I notice that the 
relationship between an entry nodeand the root of the tree is partially 
established by the use of a property on "entry node" which names the timeline 
index.
The simplest way to establish the relationship between an "entry node" and the 
tree root is by means of a Lucene index lookup.
This is of course not a very fastest solution and actually would mean the same 
as adding a property to the "resource node", listing the classes a resource is 
an instance of.
Adding a relationship from "entry node" to "tree root" in the Timeline 
component would create yet another densely populated nodein the database (in 
this case the tree root). 
Is there a way out of this situation? 
Would it be possible to partition the relationships in the database per 
relationship type per direction, so densely populated nodescan get traversed 
fast for those relationships types that are sparsely populated?
Niels
  
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] neo4j-graph-collections

[Craig Taverner]

I have previously used two solutions to deal with multiple types in btrees:

   - My first index in 2009 was a btree-like n-dim index using generics to
   support int[], long[], float[] and double[] (no strings). I used this for
   TimeLine (long[1]) and Location (double[2]). The knowledge about what type
   was used was in the code for constructing the index (whether a new index or
   accessing an existing index in the graph).
   - In December I started my amanzi-index (on
github)
   that is also btree-like, n-dimensional. But this time it can index multiple
   types in the same tree (so a float, int and string in the same tree, instead
   of being forced to have all properties of the same type). It is a re-write
   of the previous index to support Strings, and mixed types. This time it does
   save the type information in meta-data at the tree root.

The idea of using a 'comparator' class for the types is similar, but simpler
than the idea I implemented for amanzi-index, where I have mapper classes
that describe not only how to compare types, but also how to map from values
to index keys and back. This includes (to some extent) the concept of the
lucene analyser, since the mapper can decide on custom distribution of, for
example, strings and category indexes.

For both of these indexes, you configure the index up front, and then only
call index.add(node) to index a node. This will fit in well with the new
auto-indexing ideas in neo4j.

On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen
wrote:

>
>
>
>
>
> At this moment Btree only supports the primitive datatype long, while Rtree
> only supports the datatype double. For Btree it makes sense to at least
> support strings, floats, doubles and ints too. Use cases for these data
> types are pretty obvious and are Btree backed in (almost) every RDBMS
> product around.I think the best solution would be to create Comparator
> objects wrapping these primitive data types and store the class name of the
> comparator in root of the index tree. This allows users to create their own
> comparators for datatypes not covered yet. It would make sense people would
> want to store BigInt and BigDecimal objects in a Btree too, others may want
> to store dates (instead of datetime), fractions, complex numbers or even
> more exotic data types.
> Niels
> > From: sxk1...@hotmail.com
> > To: user@lists.neo4j.org
> > Date: Tue, 28 Jun 2011 22:43:24 -0700
> > Subject: Re: [Neo4j] neo4j-graph-collections
> >
> >
> > I've read through this thread in more detail and have a few thoughts,
> when you talk about type I am assuming that you are referring to an
> interface that both (Btree,Rtree) can implement, for the data types I'd like
> to understand the use cases first before implementing the different data
> types, maybe we could store types of Object instead of Long or Double and
> implement comparators in a more meaningful fashion.   Also I was wondering
> if unit tests would need to be extracted out of the spatial component and
> embedded inside the graph-collections component as well or whether we'd
> potentially need to write brand new unit tests as well.
> > Craig as I mentioned I'd love to help, let me know if it would be
> possible to fork a repo or to talk in more detail this week.
> > Regards
> >
> > > From: pd_aficion...@hotmail.com
> > > To: user@lists.neo4j.org
> > > Date: Wed, 29 Jun 2011 01:35:43 +0200
> > > Subject: Re: [Neo4j] neo4j-graph-collections
> > >
> > >
> > > As to the issue of n-dim doubles, it would be interesting to consider
> creating a set of classes of type Orderable (supporting <, <=, >, >=
> operations), this we can use in both Rtree and Btree. Right now Btree only
> supports datatype Long. This should also become more generic. A first step
> we can take is at least wrap the common datatypes in Orderable classes.
> > > Niels
> > >
> > > > Date: Wed, 29 Jun 2011 00:32:15 +0200
> > > > From: cr...@amanzi.com
> > > > To: user@lists.neo4j.org
> > > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > >
> > > > The RTree in principle should be generalizable, but the current
> > > > implementation in neo4j-spatial does make a few assumptions specific
> to
> > > > spatial data, and makes use of spatial envelopes for the tree node
> bounding
> > > > boxes. It is also specific to 2D. We could make a few improvements
> first,
> > > > like generalizing to n-dimensions, replacing the recursive search
> with a
> > > > traverser and generalizing the bounding boxes to be simple
> double-arrays.
> > > > Then the only thing left would be to decide if it is ok for it to be
> based
> > > > on n-dim doubles or should be generalized to more types.
> > > >
> > > > On Tue, Jun 28, 2011 at 11:14 PM, Saikat Kanjilal <
> sxk1...@hotmail.com>wrote:
> > > >
> > > > > I would be interested in helping out with this, let me know next
> steps.
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > On Jun 28, 2011, at 8:49 AM, Niels 

Re: [Neo4j] neo4j-graph-collections

[Rick Bullotta]

That's basically what we do - wrappers around our Location, InfoTable (2D data 
table), DateTime (JODA), JSON, and XML entities to perform those types of 
comparator actions for filtering and sorting. We also expose methods in the 
"wrappers" (which also include Double, Boolean, String, etc.) to deal with 
persistence/de-persistence in a variety of formats, including Neo, JSON, XML, 
and simple toString()/fromString().




-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On 
Behalf Of Niels Hoogeveen
Sent: Wednesday, June 29, 2011 8:25 AM
To: user@lists.neo4j.org
Subject: Re: [Neo4j] neo4j-graph-collections






At this moment Btree only supports the primitive datatype long, while Rtree 
only supports the datatype double. For Btree it makes sense to at least support 
strings, floats, doubles and ints too. Use cases for these data types are 
pretty obvious and are Btree backed in (almost) every RDBMS product around.I 
think the best solution would be to create Comparator objects wrapping these 
primitive data types and store the class name of the comparator in root of the 
index tree. This allows users to create their own comparators for datatypes not 
covered yet. It would make sense people would want to store BigInt and 
BigDecimal objects in a Btree too, others may want to store dates (instead of 
datetime), fractions, complex numbers or even more exotic data types. 
Niels
> From: sxk1...@hotmail.com
> To: user@lists.neo4j.org
> Date: Tue, 28 Jun 2011 22:43:24 -0700
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> 
> I've read through this thread in more detail and have a few thoughts, when 
> you talk about type I am assuming that you are referring to an interface that 
> both (Btree,Rtree) can implement, for the data types I'd like to understand 
> the use cases first before implementing the different data types, maybe we 
> could store types of Object instead of Long or Double and implement 
> comparators in a more meaningful fashion.   Also I was wondering if unit 
> tests would need to be extracted out of the spatial component and embedded 
> inside the graph-collections component as well or whether we'd potentially 
> need to write brand new unit tests as well.
> Craig as I mentioned I'd love to help, let me know if it would be possible to 
> fork a repo or to talk in more detail this week.
> Regards
> 
> > From: pd_aficion...@hotmail.com
> > To: user@lists.neo4j.org
> > Date: Wed, 29 Jun 2011 01:35:43 +0200
> > Subject: Re: [Neo4j] neo4j-graph-collections
> > 
> > 
> > As to the issue of n-dim doubles, it would be interesting to consider 
> > creating a set of classes of type Orderable (supporting <, <=, >, >= 
> > operations), this we can use in both Rtree and Btree. Right now Btree only 
> > supports datatype Long. This should also become more generic. A first step 
> > we can take is at least wrap the common datatypes in Orderable classes.
> > Niels
> > 
> > > Date: Wed, 29 Jun 2011 00:32:15 +0200
> > > From: cr...@amanzi.com
> > > To: user@lists.neo4j.org
> > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > 
> > > The RTree in principle should be generalizable, but the current
> > > implementation in neo4j-spatial does make a few assumptions specific to
> > > spatial data, and makes use of spatial envelopes for the tree node 
> > > bounding
> > > boxes. It is also specific to 2D. We could make a few improvements first,
> > > like generalizing to n-dimensions, replacing the recursive search with a
> > > traverser and generalizing the bounding boxes to be simple double-arrays.
> > > Then the only thing left would be to decide if it is ok for it to be based
> > > on n-dim doubles or should be generalized to more types.
> > > 
> > > On Tue, Jun 28, 2011 at 11:14 PM, Saikat Kanjilal 
> > > wrote:
> > > 
> > > > I would be interested in helping out with this, let me know next steps.
> > > >
> > > > Sent from my iPhone
> > > >
> > > > On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen 
> > > > wrote:
> > > >
> > > > >
> > > > > A couple of weeks ago Peter Neubauer set up a repository for in-graph
> > > > datastructures: https://github.com/peterneubauer/graph-collections.
> > > > > At this time of writing only the Btree/Timeline index is part of this
> > > > "component".
> > > > > In my opinion it would be interesting to move the Rtree parts of
> > > > neo-spatial to neo4j-graph-collections too.
> > > > > I looked at the code but don't feel competent to seperate out those
> > > > classes that support generic Rtrees from those classes that are clearly
> > > > spatial related.
> > > > > Is there any enthusiasm for such a project and if so, who is willing 
> > > > > and
> > > > able to do this?
> > > > > Niels
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > Neo4j mailing list
> > > > > User@lists.neo4j.org
> > > > > https://lists.neo4j.org/mailman/listinfo/user
> > > > >
> > > > 

Re: [Neo4j] neo4j-graph-collections

[Niels Hoogeveen]

At this moment Btree only supports the primitive datatype long, while Rtree 
only supports the datatype double. For Btree it makes sense to at least support 
strings, floats, doubles and ints too. Use cases for these data types are 
pretty obvious and are Btree backed in (almost) every RDBMS product around.I 
think the best solution would be to create Comparator objects wrapping these 
primitive data types and store the class name of the comparator in root of the 
index tree. This allows users to create their own comparators for datatypes not 
covered yet. It would make sense people would want to store BigInt and 
BigDecimal objects in a Btree too, others may want to store dates (instead of 
datetime), fractions, complex numbers or even more exotic data types. 
Niels
> From: sxk1...@hotmail.com
> To: user@lists.neo4j.org
> Date: Tue, 28 Jun 2011 22:43:24 -0700
> Subject: Re: [Neo4j] neo4j-graph-collections
> 
> 
> I've read through this thread in more detail and have a few thoughts, when 
> you talk about type I am assuming that you are referring to an interface that 
> both (Btree,Rtree) can implement, for the data types I'd like to understand 
> the use cases first before implementing the different data types, maybe we 
> could store types of Object instead of Long or Double and implement 
> comparators in a more meaningful fashion.   Also I was wondering if unit 
> tests would need to be extracted out of the spatial component and embedded 
> inside the graph-collections component as well or whether we'd potentially 
> need to write brand new unit tests as well.
> Craig as I mentioned I'd love to help, let me know if it would be possible to 
> fork a repo or to talk in more detail this week.
> Regards
> 
> > From: pd_aficion...@hotmail.com
> > To: user@lists.neo4j.org
> > Date: Wed, 29 Jun 2011 01:35:43 +0200
> > Subject: Re: [Neo4j] neo4j-graph-collections
> > 
> > 
> > As to the issue of n-dim doubles, it would be interesting to consider 
> > creating a set of classes of type Orderable (supporting <, <=, >, >= 
> > operations), this we can use in both Rtree and Btree. Right now Btree only 
> > supports datatype Long. This should also become more generic. A first step 
> > we can take is at least wrap the common datatypes in Orderable classes.
> > Niels
> > 
> > > Date: Wed, 29 Jun 2011 00:32:15 +0200
> > > From: cr...@amanzi.com
> > > To: user@lists.neo4j.org
> > > Subject: Re: [Neo4j] neo4j-graph-collections
> > > 
> > > The RTree in principle should be generalizable, but the current
> > > implementation in neo4j-spatial does make a few assumptions specific to
> > > spatial data, and makes use of spatial envelopes for the tree node 
> > > bounding
> > > boxes. It is also specific to 2D. We could make a few improvements first,
> > > like generalizing to n-dimensions, replacing the recursive search with a
> > > traverser and generalizing the bounding boxes to be simple double-arrays.
> > > Then the only thing left would be to decide if it is ok for it to be based
> > > on n-dim doubles or should be generalized to more types.
> > > 
> > > On Tue, Jun 28, 2011 at 11:14 PM, Saikat Kanjilal 
> > > wrote:
> > > 
> > > > I would be interested in helping out with this, let me know next steps.
> > > >
> > > > Sent from my iPhone
> > > >
> > > > On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen 
> > > > wrote:
> > > >
> > > > >
> > > > > A couple of weeks ago Peter Neubauer set up a repository for in-graph
> > > > datastructures: https://github.com/peterneubauer/graph-collections.
> > > > > At this time of writing only the Btree/Timeline index is part of this
> > > > "component".
> > > > > In my opinion it would be interesting to move the Rtree parts of
> > > > neo-spatial to neo4j-graph-collections too.
> > > > > I looked at the code but don't feel competent to seperate out those
> > > > classes that support generic Rtrees from those classes that are clearly
> > > > spatial related.
> > > > > Is there any enthusiasm for such a project and if so, who is willing 
> > > > > and
> > > > able to do this?
> > > > > Niels
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > Neo4j mailing list
> > > > > User@lists.neo4j.org
> > > > > https://lists.neo4j.org/mailman/listinfo/user
> > > > >
> > > > ___
> > > > Neo4j mailing list
> > > > User@lists.neo4j.org
> > > > https://lists.neo4j.org/mailman/listinfo/user
> > > >
> > > ___
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> >   
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> 
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/lis

[Neo4j] Database engine using Neo4j

[kriti sharma]

Dear Users,

I am developing a time capsule DB engine using Neo4j as a database.
I intend to develop three scales (temporal , geo/spatial and
egocentric/personal relationships) in the db structure.
for the geolocation part, i would like to be able to query upon a location
keyword and also some nearby places/photos/people that i have in my DB.

Do you think neo4j spatial will be a good choice for such a spatial scheme?
I have developed a timeline in the usual neo4j using timeline feature. Can I
simply integrate neo4j spatial in my existing code for neo4j in eclipse?

i am retrieving data from twitter, flickr, facebook etc. so the format of
data may not be uniform. Therefore i found Neo4j to be an excellent option.
Has some work been done in modelling a user's Facebook data(friends and
networks) relationships in Neo4j?

How should I go about storing images in the DB?

Thanks
Kriti
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Regarding developing an application with Neo4j

[Stefan Zapf]

Hi Sanju,

I'm just a newbie to neo4j, but maybe it's helpful to think about the tasks you 
are facing. There are general and neo4j specific tasks embedded in your 
questions:

1. Retrieve data from the neo4j graphs (specific neo4j question)
2. Display the data to the user  (general question on Web-app design)

Specifically, you need to retrieve the data stored in your neo4j graph. There 
are two ways to do this:

1. Embed the database in your own program and access the "directly"
2. Retrieve the data indirectly using neo4j's REST API (standalone server)
2.1. Use your own servside program that speaks with your client (Java Servlets, 
 ...)
2.2. Access the REST API directly from your client

You can find a pretty good tutorials on both 1 and 2, here: 
http://wiki.neo4j.org/content/Getting_Started_Guide . Imagine you create an 
online address book. Then you might decide for 1 and write a Java program 
running on your server and publishes its own REST API. Let's assume you can 
retrieve all addresses by GETting /addressbook/contacts . Then your java 
program retrieves all addresses stored in neo4j and sends the requested 
addressses to any client which GETs /addressbook/contacts .

Once you've decided on an embedded solution or standalone server, you will need 
to decide on how to display the data. There are two basic ways that you can 
access the data via a simple webbrowser: vendor specific solutions that are 
downloaded by your browser and run in your browser (Java Applets, Active X, 
Flash) or by making use of an AJAX framework i.e. using your Browsers in-built 
functions (Javascript, HTML, css). These questions are probably better suited 
for a specific forum on the given technology. For sake of our previous example, 
you might use the JQuery Javascript Library to access the contact stored 
/addressbok/contacts and display them to your users.

However, if your goal is actually an Neoclipse-like application. You may simply 
point your browser to host:7474 , the neo4j webadmin has a nice visualization 
tool.

Best luck
Stefan














Am 29.06.2011 13:19, schrieb sanjana sanju:
> Hello Neo4j Team,
>
> I am new to neo4j. I have gone through the documentation, Its really
> awesome. You people have done excellent work.
>
> I have developed a small or sample graph based application in Java which
> contains a data (users) who are near at some place. Its working
> perfectly. For visualization I used stand alone application (Neoclipse). It
> is also working fine and showing perfectly what I want.
>
> Now I want to re-design my application like as a web application, that means
> I want to see my database as a web content (Visualization for a web-user
> that how that user has connected with others graphically) same as like
> the functionality of neoclipse.
>
> I am technically not that sound (experience). So can any one please suggest
> me some ideas or tools to design such application.
>
> Can I use neoclipse as a web application or as a server-side application? If
> so help me out from this... to design a web application.
>
> Awaiting for your valuable suggestions.
>
> Regards,
> Sanju.
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] Regarding developing an application with Neo4j

[sanjana sanju]

Hello Neo4j Team,

I am new to neo4j. I have gone through the documentation, Its really
awesome. You people have done excellent work.

I have developed a small or sample graph based application in Java which
contains a data (users) who are near at some place. Its working
perfectly. For visualization I used stand alone application (Neoclipse). It
is also working fine and showing perfectly what I want.

Now I want to re-design my application like as a web application, that means
I want to see my database as a web content (Visualization for a web-user
that how that user has connected with others graphically) same as like
the functionality of neoclipse.

I am technically not that sound (experience). So can any one please suggest
me some ideas or tools to design such application.

Can I use neoclipse as a web application or as a server-side application? If
so help me out from this... to design a web application.

Awaiting for your valuable suggestions.

Regards,
Sanju.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] Fwd: Time capsule using Neo4j

[Mattias Persson]

Please direct your questions to the Neo4j mailing list, there you have a
much bigger chance of getting the attention that your questions deserves.

-- Forwarded message --
From: kriti sharma 
Date: 2011/6/29
Subject: Time capsule using Neo4j
To: matt...@neotechnology.com


Dear Mattias,

I am developing a time capsule using Neo4j as a database.
I intend to develop three scales (temporal , geo/spatial and
egocentric/personal relationships) in the db structure.
for the geolocation part, i would like to be able to query upon a location
keyword and also some nearby places/photos/people that i have in my DB.

Do you think neo4j spatial will be a good choice for such a spatial scheme?
I have develped a timeline in the usual neo4j using timeline feature. Can I
simply integrate neo4j spatial in my existing code for neo4j in eclipse?

i am retrieving data from twitter, flickr, facebook etc. so the format of
data may not be uniform. Therefore i found Neo4j to be an excellent option.
Has some work been done in modelling a user's Facebook data(friends and
networks) relationships in Neo4j?

How should I go about storing images in the DB?

Thanks
Kriti



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Deep search with Cypher Query Language

[Andres Taylor]

On Wed, Jun 29, 2011 at 11:32 AM, Adrian Stabiszewski <
mynewslet...@nitegate.de> wrote:

> > If the property op_type contains a Number, you can't compare it against a
> > string. Could that be the problem?
>
> Yes, op_type is a number property.
>
> I'm wondering how to specify this in the query.
>

This is what I would do:

start c=(typeIndex,`node_type`,"1")
match(c)-->(r)
where c.`node_name` ="name" and r.op_type = 8
return c,r


>
> And a different aspect of the query language concept:
> Why are you creating a new query language and not a simple query builder
> class? This could avoid all this parsing misunderstandings. In the future
> devs will create query builders for the query language anyway because they
> want to create queries on the fly. Why not save them this work? ;)
>

Well, having a language that is easy to read and write in a REPL is
powerful. It allows you to use the console in webadmin, or the shell to try
your queries before actually using them in your application. Also, we want
to be easy to use from other stacks - .NET, php and non-JVM Python comes to
mind. For these users, writing a client lib will be much easier since we
accept queries in string form.

The language doesn't stop the query builders though - it's part of my
todo-list already. If you don't want to parse a string, you shouldn't have
to, that we can definitely agree on.

Cheers,

Andrés
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Knowing the status of a transaction at the call to finish()

[Mattias Persson]

There's the TopLevelTransaction#isMarkedAsSuccessful() method, but that's
protected. Maybe you need to wrap Transaction instances yourself and expose
such a method. Something like:

public class MyTransaction implements Transaction
{
private final Transaction tx;
private boolean success;

private MyTransaction( Transaction tx )
{
this.tx = tx;
}

public static MyTransaction beginTx( GraphDatabaseService db )
{
return new MyTransaction( db.beginTx() );
}

@Override
public void failure()
{
tx.failure();
}

@Override
public void success()
{
success = true;
tx.success();
}

@Override
public void finish()
{
tx.finish();
}

public boolean isMarkedAsSuccessful()
{
return success;
}
}


2011/6/28 Rick Bullotta 

> Is there an easy way to know if the transaction used in a call to finish()
> is in a "success" or "failure" state?
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Remove all relations of a specific type

[Mattias Persson]

I think GraphDatabaseService will expose getAllRelationships() in the near
future. But until then you could do something like:

public Iterable getAllRelationshipsOfType(
GraphDatabaseService db,
final RelationshipType type )
{
return new NestingIterable( db.getAllNodes() )
{
@Override
protected Iterator createNestedIterator( Node item
)
{
return item.getRelationships( type, Direction.OUTGOING
).iterator();
}
};
}


2011/6/29 Mathias Hensel 

>
> Hello,
>
> I'm considering to create a graph that represents the primitives of a web
> site: Web pages, users, tags and other stuff. I have a collaborative filter
> that measures the similarity of web pages among them. These similarities
> should be included in the graph as relations holding the strength of the
> similarity as a property. The filtering is a batch process that should be
> run every few days. To insert the newly created relations (similarities) I
> have to delete all the old similarity relations.
>
> What yould be the best approach to do that? I couldn't find any method in
> the native API for that (I'm using the EmbeddedGraphDatabase).
>
> Thanks a lot in advance,
> Mathias
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Deep search with Cypher Query Language

[Adrian Stabiszewski]

> If the property op_type contains a Number, you can't compare it against a
> string. Could that be the problem?

Yes, op_type is a number property. 

I'm wondering how to specify this in the query. 

And a different aspect of the query language concept:
Why are you creating a new query language and not a simple query builder
class? This could avoid all this parsing misunderstandings. In the future
devs will create query builders for the query language anyway because they
want to create queries on the fly. Why not save them this work? ;)

How do you think about this?


> 
> Andrés
> 
> On Wed, Jun 29, 2011 at 8:38 AM, Adrian Stabiszewski <
> mynewslet...@nitegate.de> wrote:
> 
> > Just tested my queries with M05. Now I get the result in 6.6sec
> > instead of 10sec with M04. :) This is great! 30% improvement.
> >
> > However, I might have found a regression. One of my earlier queries
> > now gives me a SystaxError Exception:
> >
> > org.neo4j.cypher.SyntaxError: Don't know how to compare that. Left: 6;
> > Right: 8
> >at
> >
> >
> org.neo4j.cypher.Comparer$class.compareValuesOfDifferentTypes(Compar
> er
> > .scala
> > :44)
> >at
> >
> >
> org.neo4j.cypher.commands.ComparableClause.compareValuesOfDifferent
> Typ
> > es(Com
> > parableClause.scala:25)
> >at org.neo4j.cypher.Comparer$class.compare(Comparer.scala:66)
> >at
> >
> >
> org.neo4j.cypher.commands.ComparableClause.compare(ComparableClaus
> e.sc
> > ala:25
> > )
> >at
> >
> >
> org.neo4j.cypher.commands.ComparableClause.isMatch(ComparableClause.
> sc
> > ala:32
> > )
> >at org.neo4j.cypher.commands.And.isMatch(Clause.scala:31)
> >at
> >
> >
> org.neo4j.cypher.pipes.FilterPipe$$anonfun$foreach$1.apply(FilterPipe.scal
> a:
> > 31)
> >at
> >
> >
> org.neo4j.cypher.pipes.FilterPipe$$anonfun$foreach$1.apply(FilterPipe.scal
> a:
> > 30)
> >at
> >
> > scala.collection.TraversableLike$$anonfun$filter$1.apply(TraversableLi
> > ke.sca
> > la:213)
> >at
> >
> >
> scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scal
> a:
> > 194)
> >at
> >
> >
> scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scal
> a:
> > 194)
> >at
> >
> > scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.s
> > cala:5
> > 9)
> >at scala.collection.immutable.List.foreach(List.scala:45)
> >at
> > scala.collection.TraversableLike$class.map(TraversableLike.scala:194)
> >at scala.collection.immutable.List.map(List.scala:45)
> >at
> >
> >
> org.neo4j.cypher.pipes.PatternPipe$$anonfun$foreach$1.apply(PatternPip
> > e.scal
> > a:42)
> >at
> >
> >
> org.neo4j.cypher.pipes.PatternPipe$$anonfun$foreach$1.apply(PatternPip
> > e.scal
> > a:39)
> >at
> >
> > org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.sc
> > ala:36
> > )
> >at
> >
> > org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.sc
> > ala:35
> > )
> >at
> >
> > scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.s
> > cala:5
> > 9)
> >at scala.collection.immutable.List.foreach(List.scala:45)
> >at org.neo4j.cypher.pipes.StartPipe.foreach(StartPipe.scala:35)
> >at
org.neo4j.cypher.pipes.PatternPipe.foreach(PatternPipe.scala:39)
> >at
> > scala.collection.TraversableLike$class.filter(TraversableLike.scala:212)
> >at org.neo4j.cypher.pipes.Pipe.filter(Pipe.scala:31)
> >at org.neo4j.cypher.pipes.FilterPipe.foreach(FilterPipe.scala:30)
> >at
> > org.neo4j.cypher.pipes.TransformPipe.foreach(TransformPipe.scala:36)
> >at
> >
> org.neo4j.cypher.pipes.ColumnFilterPipe.foreach(ColumnFilterPipe.scala:34)
> >at
> > scala.collection.TraversableLike$class.map(TraversableLike.scala:194)
> >at org.neo4j.cypher.pipes.Pipe.map(Pipe.scala:31)
> >at
> >
> > org.neo4j.cypher.ExecutionResult$class.javaIterator(ExecutionResult.sc
> > ala:43
> > )
> >at
> >
> >
> org.neo4j.cypher.ExecutionEngine$$anon$1.javaIterator(ExecutionEngine.sc
> ala:
> > 75)
> >at
> >
> > org.neo4j.cypher.javacompat.ExecutionResult.iterator(ExecutionResult.j
> > ava:51
> > )
> >
> >
> > The query in question was:
> >
> > start c=(typeIndex,`node_type`,"1") match(c)-->(r) where
> > (c.`node_name` =
> > "name") and (r.op_type = "8") return c,r
> >
> > The "8" from the error message relates to the "8" in the where
statement.
> >
> >
> >
> >
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> >
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] numericRange vs. exact/fulltext index

[Mattias Persson]

Sure thing!

and your original problem (.toString()) is now fixed as per your suggestion.

Best,
Mattias

2011/6/29 Balazs E. Pataki 

> OK, I will then try use this as a "feature". We will always have the
> source to hack it back in case these "_e" fields go away in the future. :-)
> ---
> balazs
>
> On 6/29/11 10:22 AM, Mattias Persson wrote:
> > Reading the source is always a good thing :)
> >
> > I don't see them changing in the near future, and even if it's a bit of a
> > hack to use them (since they are there mostly to be able to remove stuff)
> > I've used them also in at least one scenario. I think you can give it a
> go,
> > but it's not an "official" feature that could potentially change.
> >
> > 2011/6/29 Balazs E. Pataki
> >
> >> Great, thank you!
> >>
> >> Another thing I just found in IndexType: for a fulltext index each field
> >> is stored as fulltext (tokenized into terms) and there's also an "exact"
> >> field (the same index postfixed with "_e"). I think this feature is not
> >> documented officially, so my question is, whether we can count on these
> >> "_e" fields to exist in the lucene index in future versions of neo4j as
> >> well? Because I would be glad to use it.
> >>
> >> In my application I have text content which I index in a "fulltext"
> >> neo4j/lucene index, but I also have to store it in "exact" form. Without
> >> knowing about this "_e" feature I had to do this "exact" indexing by
> >> tweaking the content (replacing spaces with "_" and doing the same with
> >> search terms). If I could instead depend on "_e" fields, I could get rid
> >> of my own exact index tweaking and my index would be half as big.
> >>
> >> Do you think I can safely depend on these implicit exact indexed fields
> >> in fulletxt indexes?
> >>
> >> Regards,
> >> ---
> >> balazs
> >>
> >> On 6/29/11 7:44 AM, Mattias Persson wrote:
> >>> Wow, thank you for finding that. Well done!
> >>>
> >>> I'll fix it and if it doesn't break anything else then I'll commit it.
> >>>
> >>> Best,
> >>> Mattias
> >>>
> >>> Den tisdagen den 28:e juni 2011 skrev Balazs E. Pataki<
> >> pat...@dsd.sztaki.hu>:
>  Hi Mattias,
> 
>  Thanks for the tip!
> 
>  I started to look around and I think I found something. When
> "fulltext"
>  type index is created its type will be CustomType (subclass of
> IndexType
>  - IndexType is used for "exact" indexes) in neo4j. CustomType
> overrides
>  the addToDocument() of IndexType method, which is the function that
>  actually created a Lucene field.
> 
>  IndexType's looks like this:
> 
>  public void addToDocument( Document document, String key, Object value
> )
>  {
>   document.add( instantiateField( key, value, Index.NOT_ANALYZED )
> );
>  }
> 
>  CustomType's implementation on teh other hand:
> 
>  @Override
>  public void addToDocument( Document document, String key, Object value
> )
>  {
>   document.add( new Field( exactKey( key ), value.toString(),
>  Store.YES, Index.NOT_ANALYZED ) );
>   document.add( instantiateField( key, value.toString(),
> >> Index.ANALYZED
>  ) );
>  }
> 
>  What I can see here is that CustomType's version explicitely converts
>  value to a String and therefore instantiateField won't detect it as a
>  number and will not create a NumericField for it.
> 
>  Could this be the root of the problem?
> 
>  I just replaced 'value.toString()' with 'value', and now my test runs
> OK
>  (and fulltext search for terms still work beside numeric range
> queries).
> 
>  Regards,
>  ---
>  balazs
> 
>  On 6/28/11 4:41 PM, Mattias Persson wrote:
> > Hi Balazs,
> >
> > I think the issue could be in lucene, with the mix of the
> > white-space-tokenizing-analyzer and numeric values. I don't know.
> What
> >> I see
> > in neo4j is that it treats the values the exact same way, the queries
> >> to the
> > index is exactly the same, but it just doesn't return any values. I
> >> think
> > there needs to be some more googling around this to get more answers.
> >
> >
> > 2011/6/28 Balazs E. Pataki
> >
> >> Hi,
> >>
> >> I'm playing around with indexing and numeric range queries according
> >> to
> >> this documentation:
> >>
> >>
> >> http://docs.neo4j.org/chunked/snapshot/indexing-lucene-extras.html
> >>
> >> According to my tests numeric range queries
> >> (QueryContext.numericRange()) only have effect when "exact" type
> index
> >> is used.
> >>
> >>
> >> I tried this:
> >>
> >> Transaction tx = graphDb.beginTx();
> >> try {
> >>
> >>  Index exactIndex =
> graphDb.index().forNodes("exactIndex",
> >> MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "exact"
> >> ));
> >>  Index fulltextIndex =
> >> graphDb.index().forNodes("fulltextIndex",
> >> MapUtil.st

Re: [Neo4j] NonWritableChannelException

[Mattias Persson]

I'm answering in this thread (which is the original) as well as the other
one that spawned from it:

Johan and I missed the fact that it was the read-only version that you used.
This is indeed a bug and is as of now fixed. It will go into 1.4 release.

Best,
Mattias

2011/6/28 Johan Svensson 

> Paul,
>
> This could be related to the wrapper bug found if you are running the
> server. If the server was under heavy load and entered GC trashing
> (JVM stopping all threads just running GC) the wrapper thought the
> server was unresponsive and restarted it. This problem will be fixed
> in the 1.4.M05 release.
>
> Regards,
> Johan
>
> On Tue, Jun 21, 2011 at 1:22 PM, Paul Bandler 
> wrote:
> > The above exception is thrown from the call stack indicated below while
> traversing a neo4j graph using the EmbedesReadOnly database. Using 1.4M04.
> >
> > The application is running with 1gb of heap with defaulting all other
> parameters except cache_type=weak on windows.
> >
> > I found some reports of this exception being thrown at shutdown back
> > in January but this is not happening at shutdown and I could find no
> posted resolution of that thread anyway.
> >
> > Can anyone suggest what the cause if this exception is?
> >
> > Thanks
> >
> > Paul
> >
> >>
> >
> >> Exception in thread "main" java.nio.channels.NonWritableChannelException
> >> at sun.nio.ch.FileChannelImpl.write(Unknown Source)
> >> at
> org.neo4j.kernel.impl.nioneo.store.AbstractPersistenceWindow.writeOut(AbstractPersistenceWindow.java:104)
> >> at
> org.neo4j.kernel.impl.nioneo.store.PersistenceWindowPool.refreshBricks(PersistenceWindowPool.java:536)
> >> at
> org.neo4j.kernel.impl.nioneo.store.PersistenceWindowPool.acquire(PersistenceWindowPool.java:128)
> >> at
> org.neo4j.kernel.impl.nioneo.store.CommonAbstractStore.acquireWindow(CommonAbstractStore.java:526)
> >> at
> org.neo4j.kernel.impl.nioneo.store.RelationshipStore.getChainRecord(RelationshipStore.java:327)
> >> at
> org.neo4j.kernel.impl.nioneo.xa.ReadTransaction.getMoreRelationships(ReadTransaction.java:114)
> >> at
> org.neo4j.kernel.impl.nioneo.xa.ReadTransaction.getMoreRelationships(ReadTransaction.java:97)
> >> at
> org.neo4j.kernel.impl.persistence.PersistenceManager.getMoreRelationships(PersistenceManager.java:108)
> >> at
> org.neo4j.kernel.impl.core.NodeManager.getMoreRelationships(NodeManager.java:603)
> >> at
> org.neo4j.kernel.impl.core.NodeImpl.getMoreRelationships(NodeImpl.java:399)
> >> at
> org.neo4j.kernel.impl.core.IntArrayIterator.hasNext(IntArrayIterator.java:93)
> >> at
> org.neo4j.kernel.impl.core.NodeImpl.getSingleRelationship(NodeImpl.java:218)
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Advantages of EmbeddedReadOnlyGraphDatabase ? [was NonWritableChannelException]

[Mattias Persson]

Turns out to be a bug indeed. A fix for this will go into 1.4.

Thank you,
Mattias

2011/6/29 Mattias Persson 

> AFAIK there are no differences between the two. The read-only version makes
> sure you cannot perform modifications to the graph, but otherwise they use
> the same calls and code.
>
> Regarding the NonWritableChannelException. I see that FileChannel.write()
> is called (even though nothing has changed), even when in read-only mode
> when releasing persistence windows for the persistence window implementation
> used for windows/non-memory-mapped environments. That should be the culprit
> in here. I'll try to reproduce it locally.
>
>
> 2011/6/29 Paul Bandler 
>
>> The problem resulting in the NonWritableChannelException occurred on
>> Windows although I need to run on Solaris as well as Windows.
>>
>> Actually I must apologise for saying that the previously reported issue
>> didn't solicit a response - I see that Johan Svensson did just today and
>> suggests it might be fixed in the new milestone release.
>>
>> My questions regarding what actual effect using the
>> EmbeddedReadOnlyGraphDatabase is still relevant however...?
>>
>> On 28 Jun 2011, at 21:21, Rick Bullotta wrote:
>>
>> > Paul, are you on windows or Linux?
>> >
>> > - Reply message -
>> > From: "Paul Bandler" 
>> > Date: Tue, Jun 28, 2011 1:34 pm
>> > Subject: [Neo4j] Advantages of EmbeddedReadOnlyGraphDatabase ? [was
>> NonWritableChannelException]
>> > To: "Neo4j user discussions" 
>> >
>> > Are there advantages in accessing the database via the
>> EmbeddedReadOnlyGraphDatabaseclass in a read-only application?
>> >
>> > A week or so back I posted the message below regarding a problem
>> experienced while using EmbeddedReadOnlyGraphDatabase that regrettably
>> didn't solicit any responses and since then I've been using the standard
>> read-write EmbeddedGraphDatabase without repeat of the same issue even
>> though my application is read-only. Are there any avoidable performance
>> penalties using EmbeddedGraphDatabase in place of
>> EmbeddedReadOnlyGraphDatabase?
>> >
>> > Along a similar lines, as my application is read-only, I'm not doing any
>> explicit transaction management - is there any reason why I should?
>> >
>> >
>> >
>> > Begin forwarded message:
>> >
>> > > From: Paul Bandler 
>> > > Date: 21 June 2011 12:22:56 GMT+01:00
>> > > To: Neo4j user discussions 
>> > > Subject: [Neo4j] NonWritableChannelException
>> > > Reply-To: Neo4j user discussions 
>> > >
>> > > The above exception is thrown from the call stack indicated below
>> while traversing a neo4j graph using the EmbededReadOnly database. Using
>> 1.4M04.
>> > >
>> > > The application is running with 1gb of heap with defaulting all other
>> parameters except cache_type=weak on windows.
>> > >
>> > > I found some reports of this exception being thrown at shutdown back
>> > > in January but this is not happening at shutdown and I could find no
>> posted resolution of that thread anyway.
>> > >
>> > > Can anyone suggest what the cause if this exception is?
>> > >
>> > > Thanks
>> > >
>> > > Paul
>> > >
>> > >>
>> > >
>> > >> Exception in thread "main"
>> java.nio.channels.NonWritableChannelException
>> > >>at sun.nio.ch.FileChannelImpl.write(Unknown Source)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.store.AbstractPersistenceWindow.writeOut(AbstractPersistenceWindow.java:104)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.store.PersistenceWindowPool.refreshBricks(PersistenceWindowPool.java:536)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.store.PersistenceWindowPool.acquire(PersistenceWindowPool.java:128)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.store.CommonAbstractStore.acquireWindow(CommonAbstractStore.java:526)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.store.RelationshipStore.getChainRecord(RelationshipStore.java:327)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.xa.ReadTransaction.getMoreRelationships(ReadTransaction.java:114)
>> > >>at
>> org.neo4j.kernel.impl.nioneo.xa.ReadTransaction.getMoreRelationships(ReadTransaction.java:97)
>> > >>at
>> org.neo4j.kernel.impl.persistence.PersistenceManager.getMoreRelationships(PersistenceManager.java:108)
>> > >>at
>> org.neo4j.kernel.impl.core.NodeManager.getMoreRelationships(NodeManager.java:603)
>> > >>at
>> org.neo4j.kernel.impl.core.NodeImpl.getMoreRelationships(NodeImpl.java:399)
>> > >>at
>> org.neo4j.kernel.impl.core.IntArrayIterator.hasNext(IntArrayIterator.java:93)
>> > >>at
>> org.neo4j.kernel.impl.core.NodeImpl.getSingleRelationship(NodeImpl.java:218)
>> > >>
>> > > ___
>> > > Neo4j mailing list
>> > > User@lists.neo4j.org
>> > > https://lists.neo4j.org/mailman/listinfo/user
>> >
>> > ___
>> > Neo4j mailing list
>> > User@lists.neo4j.org
>> > https://lists.neo4j.org/mailman/listinfo/user
>>
>> ___

[Neo4j] Remove all relations of a specific type

[Mathias Hensel]

Hello,

I'm considering to create a graph that represents the primitives of a web site: 
Web pages, users, tags and other stuff. I have a collaborative filter that 
measures the similarity of web pages among them. These similarities should be 
included in the graph as relations holding the strength of the similarity as a 
property. The filtering is a batch process that should be run every few days. 
To insert the newly created relations (similarities) I have to delete all the 
old similarity relations. 

What yould be the best approach to do that? I couldn't find any method in the 
native API for that (I'm using the EmbeddedGraphDatabase). 

Thanks a lot in advance, 
Mathias
  
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] numericRange vs. exact/fulltext index

[Balazs E. Pataki]

OK, I will then try use this as a "feature". We will always have the 
source to hack it back in case these "_e" fields go away in the future. :-)
---
balazs

On 6/29/11 10:22 AM, Mattias Persson wrote:
> Reading the source is always a good thing :)
>
> I don't see them changing in the near future, and even if it's a bit of a
> hack to use them (since they are there mostly to be able to remove stuff)
> I've used them also in at least one scenario. I think you can give it a go,
> but it's not an "official" feature that could potentially change.
>
> 2011/6/29 Balazs E. Pataki
>
>> Great, thank you!
>>
>> Another thing I just found in IndexType: for a fulltext index each field
>> is stored as fulltext (tokenized into terms) and there's also an "exact"
>> field (the same index postfixed with "_e"). I think this feature is not
>> documented officially, so my question is, whether we can count on these
>> "_e" fields to exist in the lucene index in future versions of neo4j as
>> well? Because I would be glad to use it.
>>
>> In my application I have text content which I index in a "fulltext"
>> neo4j/lucene index, but I also have to store it in "exact" form. Without
>> knowing about this "_e" feature I had to do this "exact" indexing by
>> tweaking the content (replacing spaces with "_" and doing the same with
>> search terms). If I could instead depend on "_e" fields, I could get rid
>> of my own exact index tweaking and my index would be half as big.
>>
>> Do you think I can safely depend on these implicit exact indexed fields
>> in fulletxt indexes?
>>
>> Regards,
>> ---
>> balazs
>>
>> On 6/29/11 7:44 AM, Mattias Persson wrote:
>>> Wow, thank you for finding that. Well done!
>>>
>>> I'll fix it and if it doesn't break anything else then I'll commit it.
>>>
>>> Best,
>>> Mattias
>>>
>>> Den tisdagen den 28:e juni 2011 skrev Balazs E. Pataki<
>> pat...@dsd.sztaki.hu>:
 Hi Mattias,

 Thanks for the tip!

 I started to look around and I think I found something. When "fulltext"
 type index is created its type will be CustomType (subclass of IndexType
 - IndexType is used for "exact" indexes) in neo4j. CustomType overrides
 the addToDocument() of IndexType method, which is the function that
 actually created a Lucene field.

 IndexType's looks like this:

 public void addToDocument( Document document, String key, Object value )
 {
  document.add( instantiateField( key, value, Index.NOT_ANALYZED ) );
 }

 CustomType's implementation on teh other hand:

 @Override
 public void addToDocument( Document document, String key, Object value )
 {
  document.add( new Field( exactKey( key ), value.toString(),
 Store.YES, Index.NOT_ANALYZED ) );
  document.add( instantiateField( key, value.toString(),
>> Index.ANALYZED
 ) );
 }

 What I can see here is that CustomType's version explicitely converts
 value to a String and therefore instantiateField won't detect it as a
 number and will not create a NumericField for it.

 Could this be the root of the problem?

 I just replaced 'value.toString()' with 'value', and now my test runs OK
 (and fulltext search for terms still work beside numeric range queries).

 Regards,
 ---
 balazs

 On 6/28/11 4:41 PM, Mattias Persson wrote:
> Hi Balazs,
>
> I think the issue could be in lucene, with the mix of the
> white-space-tokenizing-analyzer and numeric values. I don't know. What
>> I see
> in neo4j is that it treats the values the exact same way, the queries
>> to the
> index is exactly the same, but it just doesn't return any values. I
>> think
> there needs to be some more googling around this to get more answers.
>
>
> 2011/6/28 Balazs E. Pataki
>
>> Hi,
>>
>> I'm playing around with indexing and numeric range queries according
>> to
>> this documentation:
>>
>>
>> http://docs.neo4j.org/chunked/snapshot/indexing-lucene-extras.html
>>
>> According to my tests numeric range queries
>> (QueryContext.numericRange()) only have effect when "exact" type index
>> is used.
>>
>>
>> I tried this:
>>
>> Transaction tx = graphDb.beginTx();
>> try {
>>
>>  Index exactIndex = graphDb.index().forNodes("exactIndex",
>> MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "exact"
>> ));
>>  Index fulltextIndex =
>> graphDb.index().forNodes("fulltextIndex",
>> MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "fulltext"
>> ));
>>
>>  Node n1 = graphDb.createNode();
>>  n1.setProperty("foo", 5);
>>  exactIndex.add(n1, "foo", ValueContext.numeric(5));
>>  fulltextIndex.add(n1, "foo", ValueContext.numeric(5));
>>
>>  Node n2 = graphDb.createNode();
>>  n2.setProperty("foo", 25);
>>  exactIndex.add(n2, "foo", V

Re: [Neo4j] numericRange vs. exact/fulltext index

[Mattias Persson]

Reading the source is always a good thing :)

I don't see them changing in the near future, and even if it's a bit of a
hack to use them (since they are there mostly to be able to remove stuff)
I've used them also in at least one scenario. I think you can give it a go,
but it's not an "official" feature that could potentially change.

2011/6/29 Balazs E. Pataki 

> Great, thank you!
>
> Another thing I just found in IndexType: for a fulltext index each field
> is stored as fulltext (tokenized into terms) and there's also an "exact"
> field (the same index postfixed with "_e"). I think this feature is not
> documented officially, so my question is, whether we can count on these
> "_e" fields to exist in the lucene index in future versions of neo4j as
> well? Because I would be glad to use it.
>
> In my application I have text content which I index in a "fulltext"
> neo4j/lucene index, but I also have to store it in "exact" form. Without
> knowing about this "_e" feature I had to do this "exact" indexing by
> tweaking the content (replacing spaces with "_" and doing the same with
> search terms). If I could instead depend on "_e" fields, I could get rid
> of my own exact index tweaking and my index would be half as big.
>
> Do you think I can safely depend on these implicit exact indexed fields
> in fulletxt indexes?
>
> Regards,
> ---
> balazs
>
> On 6/29/11 7:44 AM, Mattias Persson wrote:
> > Wow, thank you for finding that. Well done!
> >
> > I'll fix it and if it doesn't break anything else then I'll commit it.
> >
> > Best,
> > Mattias
> >
> > Den tisdagen den 28:e juni 2011 skrev Balazs E. Pataki<
> pat...@dsd.sztaki.hu>:
> >> Hi Mattias,
> >>
> >> Thanks for the tip!
> >>
> >> I started to look around and I think I found something. When "fulltext"
> >> type index is created its type will be CustomType (subclass of IndexType
> >> - IndexType is used for "exact" indexes) in neo4j. CustomType overrides
> >> the addToDocument() of IndexType method, which is the function that
> >> actually created a Lucene field.
> >>
> >> IndexType's looks like this:
> >>
> >> public void addToDocument( Document document, String key, Object value )
> >> {
> >> document.add( instantiateField( key, value, Index.NOT_ANALYZED ) );
> >> }
> >>
> >> CustomType's implementation on teh other hand:
> >>
> >> @Override
> >> public void addToDocument( Document document, String key, Object value )
> >> {
> >> document.add( new Field( exactKey( key ), value.toString(),
> >> Store.YES, Index.NOT_ANALYZED ) );
> >> document.add( instantiateField( key, value.toString(),
> Index.ANALYZED
> >> ) );
> >> }
> >>
> >> What I can see here is that CustomType's version explicitely converts
> >> value to a String and therefore instantiateField won't detect it as a
> >> number and will not create a NumericField for it.
> >>
> >> Could this be the root of the problem?
> >>
> >> I just replaced 'value.toString()' with 'value', and now my test runs OK
> >> (and fulltext search for terms still work beside numeric range queries).
> >>
> >> Regards,
> >> ---
> >> balazs
> >>
> >> On 6/28/11 4:41 PM, Mattias Persson wrote:
> >>> Hi Balazs,
> >>>
> >>> I think the issue could be in lucene, with the mix of the
> >>> white-space-tokenizing-analyzer and numeric values. I don't know. What
> I see
> >>> in neo4j is that it treats the values the exact same way, the queries
> to the
> >>> index is exactly the same, but it just doesn't return any values. I
> think
> >>> there needs to be some more googling around this to get more answers.
> >>>
> >>>
> >>> 2011/6/28 Balazs E. Pataki
> >>>
>  Hi,
> 
>  I'm playing around with indexing and numeric range queries according
> to
>  this documentation:
> 
> 
> http://docs.neo4j.org/chunked/snapshot/indexing-lucene-extras.html
> 
>  According to my tests numeric range queries
>  (QueryContext.numericRange()) only have effect when "exact" type index
>  is used.
> 
> 
>  I tried this:
> 
>  Transaction tx = graphDb.beginTx();
>  try {
> 
>  IndexexactIndex = graphDb.index().forNodes("exactIndex",
>  MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "exact"
> ));
>  IndexfulltextIndex =
> graphDb.index().forNodes("fulltextIndex",
>  MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "fulltext"
> ));
> 
>  Node n1 = graphDb.createNode();
>  n1.setProperty("foo", 5);
>  exactIndex.add(n1, "foo", ValueContext.numeric(5));
>  fulltextIndex.add(n1, "foo", ValueContext.numeric(5));
> 
>  Node n2 = graphDb.createNode();
>  n2.setProperty("foo", 25);
>  exactIndex.add(n2, "foo", ValueContext.numeric(25));
>  fulltextIndex.add(n2, "foo", ValueContext.numeric(25));
> 
>  // Force commit
>  tx.success();
>  tx.finish();
>  tx = graphDb.beginTx();
> 
>  //Search exact
>  QueryCont

Re: [Neo4j] Auto Indexing for Neo4j

[Mattias Persson]

This first version of auto indexing is only exact index and their names are
"node_auto_index"/"relationship_auto_index". They are normal indexes
otherwise (just read-only). Although in M05 they can be modified, but this
will be fixed today I think.

2011/6/29 Matt Luongo 

> Peter,
>
> Did this get done before the feature freeze? I'm still trying to find a way
> to query/configure an autoindex via REST.
>
> --
> Matt Luongo
> Co-Founder, Scholr.ly
>
> On Tue, Jun 14, 2011 at 5:32 PM, Peter Neubauer <
> peter.neuba...@neotechnology.com> wrote:
>
> > Yes,
> > configuration and indexing via REST is the next step for this.
> >
> > Cheers,
> >
> > /peter neubauer
> >
> > GTalk:  neubauer.peter
> > Skype   peter.neubauer
> > Phone   +46 704 106975
> > LinkedIn   http://www.linkedin.com/in/neubauer
> > Twitter  http://twitter.com/peterneubauer
> >
> > http://www.neo4j.org   - Your high performance graph
> database.
> > http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> > http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
> >
> >
> >
> > On Tue, Jun 14, 2011 at 7:25 PM, Aseem Kishore 
> > wrote:
> > > Awesome to hear, and great work! Will we be able to configure+use this
> > from
> > > the REST API?
> > >
> > > Cheers,
> > > Aseem
> > >
> > > On Tue, Jun 14, 2011 at 8:30 AM, Chris Gioran <
> > > chris.gio...@neotechnology.com> wrote:
> > >
> > >> Good news everyone,
> > >>
> > >> A request that's often come up on the mailing list is a mechanism for
> > >> automatically indexing properties of nodes and relationships.
> > >>
> > >> As of today's SNAPSHOT, auto-indexing is part of Neo4j which means
> nodes
> > >> and relationships can now be indexed based on convention, requiring
> > >> far less effort and code from the developer's point of view.
> > >>
> > >> Getting hold of an automatic index is straightforward:
> > >>
> > >> AutoIndexer nodeAutoIndexer =
> > graphDb.index().getNodeAutoIndexer();
> > >> AutoIndex nodeAutoIndex = nodeAutoIndexer.getAutoIndex();
> > >>
> > >> Once you've got an instance of AutoIndex, you can use it as a
> read-only
> > >> Index.
> > >>
> > >> The AutoIndexer interface also supports runtime changes and
> > >> enabling/disabling the auto indexing functionality.
> > >>
> > >> To support the new features, there are new Config
> > >> options you can pass to the startup configuration map in
> > >> EmbeddedGraphDatabase, the most important of which are:
> > >>
> > >> Config.NODE_AUTO_INDEXING (defaults to "false")
> > >> Config.RELATIONSHIP_AUTO_INDEXING (defaults to "false")
> > >>
> > >> If set to "true" (independently of each other) these properties will
> > >> enable auto indexing functionality and at the successful finish() of
> > >> each transaction, all newly added properties on the primitives for
> which
> > >> auto indexing is enabled will be added to a special AutoIndex (and
> > >> deleted or changed properties will be updated accordingly too).
> > >>
> > >> There are options for fine grained control to determine
> > >> properties are indexed, default behaviors and so forth. For example,
> by
> > >> default all properties are indexed. If you want only properties "name"
> > and
> > >> "age" for Nodes and "since" and "until" for Relationships
> > >> to be auto indexed, simply set the initial configuration as follows:
> > >>
> > >> Config.NODE_KEYS_INDEXABLE = "name, age";
> > >> Config.RELATIONSHIP_KEYS_INDEXABLE="since, until";
> > >>
> > >> For the semantics of the auto-indexing operations, constraints and
> more
> > >> detailed examples, see the documentation available  at
> > >>
> > >> http://docs.neo4j.org/chunked/1.4-SNAPSHOT/auto-indexing.html
> > >>
> > >> We're pretty excited about this feature since we think it'll make your
> > >> lives
> > >> as developers much more productive in a range of use-cases. If you're
> > >> comfortable with using SNAPSHOT versions of Neo4j, please try it out
> > >> and let us know what you think - we'd really value your feedback.
> > >>
> > >> If you're happier with using packaged milestones then this feature
> > >> will be available from 1.4 M05 in a couple of weeks from now.
> > >> ___
> > >> Neo4j mailing list
> > >> User@lists.neo4j.org
> > >> https://lists.neo4j.org/mailman/listinfo/user
> > >>
> > > ___
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> > >
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> >
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org

Re: [Neo4j] Announcing the latest milestone (1.4.M05)

[Aseem Kishore]

Aw, that's too bad. =( We were really looking forward to auto-indexing, and
we only use Neo4j via the REST API, as our app is a Node.js app, not a Java
one.

It would be great to see even something basic. If there's anything we can do
to help, let us know.

Cheers,
Aseem

On Wed, Jun 29, 2011 at 12:22 AM, Chris Gioran <
chris.gio...@neotechnology.com> wrote:

> Hi Aseem,
>
> there is currently no ability to configure the auto indexer from the
> REST API. It is definite that this functionality will be added but it
> is unclear at this time when this will happen. We would be happy as
> well though if this was included in 1.4 GA.
>
> cheers,
> CG
>
> On Wed, Jun 29, 2011 at 8:46 AM, Aseem Kishore 
> wrote:
> > Awesome stuff!
> >
> > One question: is there any ability yet to use (i.e. configure)
> auto-indexing
> > from the REST API? If not, will that be a part of 1.4 final?
> >
> > Cheers,
> > Aseem
> >
> > On Tue, Jun 28, 2011 at 7:03 AM, Andres Taylor <
> > andres.tay...@neotechnology.com> wrote:
> >
> >> Hello graphistas,
> >>
> >> Today we’re releasing the fifth and final milestone in our 1.4 “Kiruna
> >> Stol”
> >> family. We’ve expanded our feature set to include Auto Indexing and
> paged
> >> traversers for the REST API, the Cypher query language has seen some
> major
> >> improvements and as always, we’ve squeezed more performance out of our
> >> database engine.
> >>
> >> Auto indexing
> >> --
> >> In this milestone we have included an improved version of the auto
> indexing
> >> functionality that was announced shortly after 1.4.M04 and has been
> >> available in development snapshots since then. You’ll now find new
> >> configuration options for separately enabling auto indexing for node and
> >> relationship properties and for defining which properties will be
> indexed.
> >> For example, if you want to auto-index all node properties called “name”
> >> and
> >> all relationship properties called “since” the proper configuration is:
> >>
> >> Map config = new HashMap();
> >> config.put(Config.NODE_AUTO_INDEXING, “true”);
> >> config.put(Config.NODE_KEYS_INDEXABLE, “name”);
> >> config.put(Config.RELATIONSHIP_AUTO_INDEXING, “true”);
> >> config.put(Config.RELATIONSHIP_KEYS_INDEXABLE, “since”);
> >>
> >> Passing the above to the GraphDatabaseService constructor will enable
> auto
> >> indexing for matching nodes and relationships, and on every commit the
> auto
> >> index will be updated automatically. For more details, check out the
> >> javadocs and the examples in the manual available at:
> >>
> >> http://docs.neo4j.org/chunked/1.4.M05/auto-indexing.html
> >>
> >> Paged REST Traversers
> >> 
> >> After including batch operations in the previous milestone, now we also
> >> provide the option to page results of traversals via a special URI
> >> contained
> >> in Node representations and that is similar to the existing Traverser
> REST
> >> API. You can define the page size and lease time, having this way finer
> >> control the retrieval of traverser results from the client (and also
> help
> >> improve performance on the server).
> >>
> >> Cypher improvements
> >> -
> >> The newly introduced Cypher query language is growing more sophisticated
> >> and
> >> in this milestone we’ve added aggregates, ordering and limits. This
> allows
> >> for more expressive queries, making the following a valid statement
> against
> >> the cineasts database:
> >>
> >> START user=(User,login,'micha')
> >> MATCH (user)-[:FRIEND]-(friend)-[r,:RATED]->(movie)
> >> RETURN movie.title, AVG(r.stars), COUNT(*)
> >>   ORDER BY AVG(r.stars) DESC, COUNT(*) DESC limit 7
> >>
> >> To see Cypher in action, check out the
> >> screencastby
> >> our own Michael Hunger.
> >>
> >> Almost there
> >> 
> >> Of course that is not all. As always, we have bug fixes, performance
> >> improvements and usability enhancements, the most prevalent of which is
> the
> >> removal of YAJSW as the wrapper and service installer, which should
> bring
> >> joy to the mac users among us.
> >>
> >> With the GA release to follow shortly, we’d like you to download, try
> out
> >> and provide us with your valuable feedback on these new features so that
> we
> >> can deliver the best possible 1.4 to you, our community. For more
> details
> >> and links go to the release announcement
> >> here<
> http://blog.neo4j.org/2011/06/neo4j-14-m05-kiruna-stol-midsummer.html
> >> >
> >> .
> >>
> >> Andrés Taylor
> >> ___
> >> Neo4j mailing list
> >> User@lists.neo4j.org
> >> https://lists.neo4j.org/mailman/listinfo/user
> >>
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
> >
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://

Re: [Neo4j] numericRange vs. exact/fulltext index

[Balazs E. Pataki]

Great, thank you!

Another thing I just found in IndexType: for a fulltext index each field 
is stored as fulltext (tokenized into terms) and there's also an "exact" 
field (the same index postfixed with "_e"). I think this feature is not 
documented officially, so my question is, whether we can count on these 
"_e" fields to exist in the lucene index in future versions of neo4j as 
well? Because I would be glad to use it.

In my application I have text content which I index in a "fulltext" 
neo4j/lucene index, but I also have to store it in "exact" form. Without 
knowing about this "_e" feature I had to do this "exact" indexing by 
tweaking the content (replacing spaces with "_" and doing the same with 
search terms). If I could instead depend on "_e" fields, I could get rid 
of my own exact index tweaking and my index would be half as big.

Do you think I can safely depend on these implicit exact indexed fields 
in fulletxt indexes?

Regards,
---
balazs

On 6/29/11 7:44 AM, Mattias Persson wrote:
> Wow, thank you for finding that. Well done!
>
> I'll fix it and if it doesn't break anything else then I'll commit it.
>
> Best,
> Mattias
>
> Den tisdagen den 28:e juni 2011 skrev Balazs E. Pataki:
>> Hi Mattias,
>>
>> Thanks for the tip!
>>
>> I started to look around and I think I found something. When "fulltext"
>> type index is created its type will be CustomType (subclass of IndexType
>> - IndexType is used for "exact" indexes) in neo4j. CustomType overrides
>> the addToDocument() of IndexType method, which is the function that
>> actually created a Lucene field.
>>
>> IndexType's looks like this:
>>
>> public void addToDocument( Document document, String key, Object value )
>> {
>> document.add( instantiateField( key, value, Index.NOT_ANALYZED ) );
>> }
>>
>> CustomType's implementation on teh other hand:
>>
>> @Override
>> public void addToDocument( Document document, String key, Object value )
>> {
>> document.add( new Field( exactKey( key ), value.toString(),
>> Store.YES, Index.NOT_ANALYZED ) );
>> document.add( instantiateField( key, value.toString(), Index.ANALYZED
>> ) );
>> }
>>
>> What I can see here is that CustomType's version explicitely converts
>> value to a String and therefore instantiateField won't detect it as a
>> number and will not create a NumericField for it.
>>
>> Could this be the root of the problem?
>>
>> I just replaced 'value.toString()' with 'value', and now my test runs OK
>> (and fulltext search for terms still work beside numeric range queries).
>>
>> Regards,
>> ---
>> balazs
>>
>> On 6/28/11 4:41 PM, Mattias Persson wrote:
>>> Hi Balazs,
>>>
>>> I think the issue could be in lucene, with the mix of the
>>> white-space-tokenizing-analyzer and numeric values. I don't know. What I see
>>> in neo4j is that it treats the values the exact same way, the queries to the
>>> index is exactly the same, but it just doesn't return any values. I think
>>> there needs to be some more googling around this to get more answers.
>>>
>>>
>>> 2011/6/28 Balazs E. Pataki
>>>
 Hi,

 I'm playing around with indexing and numeric range queries according to
 this documentation:

 http://docs.neo4j.org/chunked/snapshot/indexing-lucene-extras.html

 According to my tests numeric range queries
 (QueryContext.numericRange()) only have effect when "exact" type index
 is used.


 I tried this:

 Transaction tx = graphDb.beginTx();
 try {

 IndexexactIndex = graphDb.index().forNodes("exactIndex",
 MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "exact" ));
 IndexfulltextIndex = 
 graphDb.index().forNodes("fulltextIndex",
 MapUtil.stringMap( IndexManager.PROVIDER, "lucene", "type", "fulltext" ));

 Node n1 = graphDb.createNode();
 n1.setProperty("foo", 5);
 exactIndex.add(n1, "foo", ValueContext.numeric(5));
 fulltextIndex.add(n1, "foo", ValueContext.numeric(5));

 Node n2 = graphDb.createNode();
 n2.setProperty("foo", 25);
 exactIndex.add(n2, "foo", ValueContext.numeric(25));
 fulltextIndex.add(n2, "foo", ValueContext.numeric(25));

 // Force commit
 tx.success();
 tx.finish();
 tx = graphDb.beginTx();

 //Search exact
 QueryContext qctx = QueryContext.numericRange("foo", 3, 25);
 IndexHitshits = exactIndex.query(qctx);
 Iteratorit = hits.iterator();
 while (it.hasNext()) {
 Node n = it.next();
 System.out.println("Found foo in exact: "+n+":
 "+n.getProperty("foo"));
 }
 assertEquals(2, hits.size());

 //Search fulltext
 qctx = QueryContext.numericRange("foo", 3, 25);
 hits = fulltextIndex.query(qctx);
 it = hits.iterator();
 while (it.hasNext()) {
 Node n = it.next();
 System.out.println("Found foo in full

Re: [Neo4j] Advantages of EmbeddedReadOnlyGraphDatabase ? [was NonWritableChannelException]

[Mattias Persson]

AFAIK there are no differences between the two. The read-only version makes
sure you cannot perform modifications to the graph, but otherwise they use
the same calls and code.

Regarding the NonWritableChannelException. I see that FileChannel.write() is
called (even though nothing has changed), even when in read-only mode when
releasing persistence windows for the persistence window implementation used
for windows/non-memory-mapped environments. That should be the culprit in
here. I'll try to reproduce it locally.

2011/6/29 Paul Bandler 

> The problem resulting in the NonWritableChannelException occurred on
> Windows although I need to run on Solaris as well as Windows.
>
> Actually I must apologise for saying that the previously reported issue
> didn't solicit a response - I see that Johan Svensson did just today and
> suggests it might be fixed in the new milestone release.
>
> My questions regarding what actual effect using the
> EmbeddedReadOnlyGraphDatabase is still relevant however...?
>
> On 28 Jun 2011, at 21:21, Rick Bullotta wrote:
>
> > Paul, are you on windows or Linux?
> >
> > - Reply message -
> > From: "Paul Bandler" 
> > Date: Tue, Jun 28, 2011 1:34 pm
> > Subject: [Neo4j] Advantages of EmbeddedReadOnlyGraphDatabase ? [was
> NonWritableChannelException]
> > To: "Neo4j user discussions" 
> >
> > Are there advantages in accessing the database via the
> EmbeddedReadOnlyGraphDatabaseclass in a read-only application?
> >
> > A week or so back I posted the message below regarding a problem
> experienced while using EmbeddedReadOnlyGraphDatabase that regrettably
> didn't solicit any responses and since then I've been using the standard
> read-write EmbeddedGraphDatabase without repeat of the same issue even
> though my application is read-only. Are there any avoidable performance
> penalties using EmbeddedGraphDatabase in place of
> EmbeddedReadOnlyGraphDatabase?
> >
> > Along a similar lines, as my application is read-only, I'm not doing any
> explicit transaction management - is there any reason why I should?
> >
> >
> >
> > Begin forwarded message:
> >
> > > From: Paul Bandler 
> > > Date: 21 June 2011 12:22:56 GMT+01:00
> > > To: Neo4j user discussions 
> > > Subject: [Neo4j] NonWritableChannelException
> > > Reply-To: Neo4j user discussions 
> > >
> > > The above exception is thrown from the call stack indicated below while
> traversing a neo4j graph using the EmbededReadOnly database. Using 1.4M04.
> > >
> > > The application is running with 1gb of heap with defaulting all other
> parameters except cache_type=weak on windows.
> > >
> > > I found some reports of this exception being thrown at shutdown back
> > > in January but this is not happening at shutdown and I could find no
> posted resolution of that thread anyway.
> > >
> > > Can anyone suggest what the cause if this exception is?
> > >
> > > Thanks
> > >
> > > Paul
> > >
> > >>
> > >
> > >> Exception in thread "main"
> java.nio.channels.NonWritableChannelException
> > >>at sun.nio.ch.FileChannelImpl.write(Unknown Source)
> > >>at
> org.neo4j.kernel.impl.nioneo.store.AbstractPersistenceWindow.writeOut(AbstractPersistenceWindow.java:104)
> > >>at
> org.neo4j.kernel.impl.nioneo.store.PersistenceWindowPool.refreshBricks(PersistenceWindowPool.java:536)
> > >>at
> org.neo4j.kernel.impl.nioneo.store.PersistenceWindowPool.acquire(PersistenceWindowPool.java:128)
> > >>at
> org.neo4j.kernel.impl.nioneo.store.CommonAbstractStore.acquireWindow(CommonAbstractStore.java:526)
> > >>at
> org.neo4j.kernel.impl.nioneo.store.RelationshipStore.getChainRecord(RelationshipStore.java:327)
> > >>at
> org.neo4j.kernel.impl.nioneo.xa.ReadTransaction.getMoreRelationships(ReadTransaction.java:114)
> > >>at
> org.neo4j.kernel.impl.nioneo.xa.ReadTransaction.getMoreRelationships(ReadTransaction.java:97)
> > >>at
> org.neo4j.kernel.impl.persistence.PersistenceManager.getMoreRelationships(PersistenceManager.java:108)
> > >>at
> org.neo4j.kernel.impl.core.NodeManager.getMoreRelationships(NodeManager.java:603)
> > >>at
> org.neo4j.kernel.impl.core.NodeImpl.getMoreRelationships(NodeImpl.java:399)
> > >>at
> org.neo4j.kernel.impl.core.IntArrayIterator.hasNext(IntArrayIterator.java:93)
> > >>at
> org.neo4j.kernel.impl.core.NodeImpl.getSingleRelationship(NodeImpl.java:218)
> > >>
> > > ___
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> >
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

Re: [Neo4j] Announcing the latest milestone (1.4.M05)

[Chris Gioran]

Hi Aseem,

there is currently no ability to configure the auto indexer from the
REST API. It is definite that this functionality will be added but it
is unclear at this time when this will happen. We would be happy as
well though if this was included in 1.4 GA.

cheers,
CG

On Wed, Jun 29, 2011 at 8:46 AM, Aseem Kishore  wrote:
> Awesome stuff!
>
> One question: is there any ability yet to use (i.e. configure) auto-indexing
> from the REST API? If not, will that be a part of 1.4 final?
>
> Cheers,
> Aseem
>
> On Tue, Jun 28, 2011 at 7:03 AM, Andres Taylor <
> andres.tay...@neotechnology.com> wrote:
>
>> Hello graphistas,
>>
>> Today we’re releasing the fifth and final milestone in our 1.4 “Kiruna
>> Stol”
>> family. We’ve expanded our feature set to include Auto Indexing and paged
>> traversers for the REST API, the Cypher query language has seen some major
>> improvements and as always, we’ve squeezed more performance out of our
>> database engine.
>>
>> Auto indexing
>> --
>> In this milestone we have included an improved version of the auto indexing
>> functionality that was announced shortly after 1.4.M04 and has been
>> available in development snapshots since then. You’ll now find new
>> configuration options for separately enabling auto indexing for node and
>> relationship properties and for defining which properties will be indexed.
>> For example, if you want to auto-index all node properties called “name”
>> and
>> all relationship properties called “since” the proper configuration is:
>>
>> Map config = new HashMap();
>> config.put(Config.NODE_AUTO_INDEXING, “true”);
>> config.put(Config.NODE_KEYS_INDEXABLE, “name”);
>> config.put(Config.RELATIONSHIP_AUTO_INDEXING, “true”);
>> config.put(Config.RELATIONSHIP_KEYS_INDEXABLE, “since”);
>>
>> Passing the above to the GraphDatabaseService constructor will enable auto
>> indexing for matching nodes and relationships, and on every commit the auto
>> index will be updated automatically. For more details, check out the
>> javadocs and the examples in the manual available at:
>>
>> http://docs.neo4j.org/chunked/1.4.M05/auto-indexing.html
>>
>> Paged REST Traversers
>> 
>> After including batch operations in the previous milestone, now we also
>> provide the option to page results of traversals via a special URI
>> contained
>> in Node representations and that is similar to the existing Traverser REST
>> API. You can define the page size and lease time, having this way finer
>> control the retrieval of traverser results from the client (and also help
>> improve performance on the server).
>>
>> Cypher improvements
>> -
>> The newly introduced Cypher query language is growing more sophisticated
>> and
>> in this milestone we’ve added aggregates, ordering and limits. This allows
>> for more expressive queries, making the following a valid statement against
>> the cineasts database:
>>
>> START user=(User,login,'micha')
>> MATCH (user)-[:FRIEND]-(friend)-[r,:RATED]->(movie)
>> RETURN movie.title, AVG(r.stars), COUNT(*)
>>       ORDER BY AVG(r.stars) DESC, COUNT(*) DESC limit 7
>>
>> To see Cypher in action, check out the
>> screencastby
>> our own Michael Hunger.
>>
>> Almost there
>> 
>> Of course that is not all. As always, we have bug fixes, performance
>> improvements and usability enhancements, the most prevalent of which is the
>> removal of YAJSW as the wrapper and service installer, which should bring
>> joy to the mac users among us.
>>
>> With the GA release to follow shortly, we’d like you to download, try out
>> and provide us with your valuable feedback on these new features so that we
>> can deliver the best possible 1.4 to you, our community. For more details
>> and links go to the release announcement
>> here> >
>> .
>>
>> Andrés Taylor
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Deep search with Cypher Query Language

[Andres Taylor]

If the property op_type contains a Number, you can't compare it against a
string. Could that be the problem?

Andrés

On Wed, Jun 29, 2011 at 8:38 AM, Adrian Stabiszewski <
mynewslet...@nitegate.de> wrote:

> Just tested my queries with M05. Now I get the result in 6.6sec instead of
> 10sec with M04. :) This is great! 30% improvement.
>
> However, I might have found a regression. One of my earlier queries now
> gives me a SystaxError Exception:
>
> org.neo4j.cypher.SyntaxError: Don't know how to compare that. Left: 6;
> Right: 8
>at
>
> org.neo4j.cypher.Comparer$class.compareValuesOfDifferentTypes(Comparer.scala
> :44)
>at
>
> org.neo4j.cypher.commands.ComparableClause.compareValuesOfDifferentTypes(Com
> parableClause.scala:25)
>at org.neo4j.cypher.Comparer$class.compare(Comparer.scala:66)
>at
>
> org.neo4j.cypher.commands.ComparableClause.compare(ComparableClause.scala:25
> )
>at
>
> org.neo4j.cypher.commands.ComparableClause.isMatch(ComparableClause.scala:32
> )
>at org.neo4j.cypher.commands.And.isMatch(Clause.scala:31)
>at
>
> org.neo4j.cypher.pipes.FilterPipe$$anonfun$foreach$1.apply(FilterPipe.scala:
> 31)
>at
>
> org.neo4j.cypher.pipes.FilterPipe$$anonfun$foreach$1.apply(FilterPipe.scala:
> 30)
>at
>
> scala.collection.TraversableLike$$anonfun$filter$1.apply(TraversableLike.sca
> la:213)
>at
>
> scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:
> 194)
>at
>
> scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:
> 194)
>at
>
> scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:5
> 9)
>at scala.collection.immutable.List.foreach(List.scala:45)
>at
> scala.collection.TraversableLike$class.map(TraversableLike.scala:194)
>at scala.collection.immutable.List.map(List.scala:45)
>at
>
> org.neo4j.cypher.pipes.PatternPipe$$anonfun$foreach$1.apply(PatternPipe.scal
> a:42)
>at
>
> org.neo4j.cypher.pipes.PatternPipe$$anonfun$foreach$1.apply(PatternPipe.scal
> a:39)
>at
>
> org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.scala:36
> )
>at
>
> org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.scala:35
> )
>at
>
> scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:5
> 9)
>at scala.collection.immutable.List.foreach(List.scala:45)
>at org.neo4j.cypher.pipes.StartPipe.foreach(StartPipe.scala:35)
>at org.neo4j.cypher.pipes.PatternPipe.foreach(PatternPipe.scala:39)
>at
> scala.collection.TraversableLike$class.filter(TraversableLike.scala:212)
>at org.neo4j.cypher.pipes.Pipe.filter(Pipe.scala:31)
>at org.neo4j.cypher.pipes.FilterPipe.foreach(FilterPipe.scala:30)
>at
> org.neo4j.cypher.pipes.TransformPipe.foreach(TransformPipe.scala:36)
>at
> org.neo4j.cypher.pipes.ColumnFilterPipe.foreach(ColumnFilterPipe.scala:34)
>at
> scala.collection.TraversableLike$class.map(TraversableLike.scala:194)
>at org.neo4j.cypher.pipes.Pipe.map(Pipe.scala:31)
>at
>
> org.neo4j.cypher.ExecutionResult$class.javaIterator(ExecutionResult.scala:43
> )
>at
>
> org.neo4j.cypher.ExecutionEngine$$anon$1.javaIterator(ExecutionEngine.scala:
> 75)
>at
>
> org.neo4j.cypher.javacompat.ExecutionResult.iterator(ExecutionResult.java:51
> )
>
>
> The query in question was:
>
> start c=(typeIndex,`node_type`,"1") match(c)-->(r) where (c.`node_name` =
> "name") and (r.op_type = "8") return c,r
>
> The "8" from the error message relates to the "8" in the where statement.
>
>
>
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user