I want to index the existing relationship properties in Neo4J (2.0.1) and also to set up automatic indexing for the ones that will appear in the future.
I found out that it's possible to do that in Neo4J documentation through the legacy auto-indexing as well as the examples of some Java code.
However, as I'm neither an expert in Java, nor want to use "legacy" functionality, I wanted to ask you if there is an easy way to index relationships on a specific property using Cypher command or any other way (rest API?) that wouldn't involve me having to write some Java program and run it (I don't know how to do that).
Thank you for your help!
My original answer was wrong. Editing so that it doesn't generate confusion to others looking for a solution.
Please refer to Relationship Labels and Index in Neo4J a for correct answer, as #deemeetree pointed out in the comments.
Since Neo4j 4.3 (released June 17, 2021), creating relationship property indexes can be done directly with Cypher, as discussed on the Neo4j blog and the 4.3 release notes.
Example from the blog:
CREATE INDEX officerRelationshipProperty
FOR ()-[r:OFFICER_OF]-()
ON (r.role);
You can't do indexing on relationship. Indexing is done only on nodes.
Related
In older versions of Neo4j (2.3 and prior), you could associate legacy indexes with relationship properties, but that does not appear to be the case any more. However, in the API documentation, there is org.neo4j.graphdb.index with an IndexManager parameter. When you look at IndexManager, there is a RelationshipIndex method - which suggests that this is or may soon be available. My use case is I am constructing a product hierarchy with products, product parts, product sub-parts, etc. and it's important IN THE RELATIONSHIP to have a start and end date between each set of components. Does anybody know of a way to do that in 3.x?
Legacy (or manual) indexing is still supported in 3.x. In particular, relationship indexing is still supported. Refer to the documentation for more info.
I am using neo4j.rb as the ORM for a Rails app, talking to a simple neo4j schema. I have a bunch of Person nodes and each node has two fields name and bio.
My goal is to be able to (a) search for people using a fuzzy name search which is case insensitive; (b) be able to do a full text search of the bio.
I am very confused about how indexing/searching works in neo4j. Not sure I fully understand the difference between 'schema' and 'legacy' indexing, or how Lucene fits into all of this. Most importantly, I do not understand which features neo4j.rb actually supports.
Thanks in advance.
I'm one of the maintainers of the Neo4jrb project. Indexing is pretty confusing for everyone but I can break it down pretty easily for you.
The gem doesn't deal with legacy indexing at all. The "legacy" designation suggests to us that it's not going to be around forever and that coupled with the fact that it's a bit clunky to use led us to decide not to implement it. Everything in the gem uses labels and property indexes, which are all Lucene exact indexes under the hood.
When it comes to search, if you want case insensitive and/or full-text search, you can do that in Cypher and the gem but it's going to work outside of indexes and it may be sluggish. It all depends on your data. This shows you how to do regex with Cypher. In the gem, you can do it like this:
User.where(name: /?ob/)
# or
User.as(:u).where("u.name =~ '?ob`")
My personal suggestion is to use the Searchkick gem to provide these features. It uses Elasticsearch, which uses Lucene, which is what Neo4j is using anyway, so you'll get more control and the same performance as you would with legacy indexing. The downside is you have one more moving part of your setup, but I think it's worth it.
Hope this clears it up. I'm going to add an area to the wiki about it since it's a pretty common question. Post here, open an issue on Github, or shoot me an email if you want to talk more about it.
EDIT: I added this to the documentation.
I am using hibernate-core and hibernate-search. Like I can take a look to the persisted entities with hibernate-core using some database-frontend, I need a frontend for hibernate-search/lucene to take a look at the lucene index.
I tried the latest luke, but it is alpha and does not work correctly for me.
Solr seems to have some web-frontends. But it is an alternative to hibernate-search, and it is hard to integrate with, if I understand everything I read correctly.
My wish is to see, what terms are indexed for specific entites (and its relations).
Any ideas? TIA!
You could try the Hibernate Search Eclipse plugin:
https://marketplace.eclipse.org/content/hibernate-search-plugin
Introduced first on the Hibernate Search blog.
I'm developing context discover system - which is mix of searching and suggestions.
Currently I'm looking for library for indexing.
After some investigation I stayed on Lucene and Terrier and found Indri not comfortable.
What are the downsides of both? What problem I can meet while using them?
Is it true that Terrier doesn't have incremental indexing (every time new document is added, I need to rebuild and reindex everything)?
My requirements are:
- easy adding new documents
- easy score methods injection
- quiet well defined model
And one more thing: is Terrier still active? I haven't seen any update since 10/03/2010 terrier changelog
What sort of database are you going to be using? Lucene, in my experience, is much better documented than Terrier.
Here's an article comparing Lucene and Terrier:
http://text-analytics.blogspot.com/2011/05/java-based-retrieval-toolkits.html
I'm looking into using Lucene and/or Solr to provide search in an RDBMS-powered web application. Unfortunately for me, all the documentation I've skimmed deals with how to get the data out of the index; I'm more concerned with how to build a useful index. Are there any "best practices" for doing this?
Will multiple applications be writing to the database? If so, it's a bit tricky; you have to have some mechanism to identify new records to feed to the Lucene indexer.
Another point to consider is do you want one index that covers all of your tables, or one index per table. In general, I recommend one index, with a field in that index to indicate which table the record came from.
Hibernate has support for full text search, if you want to search persistent objects rather than unstructured documents.
There's an OpenSymphony project called Compass of which you should be aware. I have stayed away from it myself, primarily because it seems to be way more complicated than search needs to be. Also, as I can tell from the documentation (I confess I haven't found the time necessary to read it all), it stores Lucene segments as blobs in the database. If you're familiar with the Lucene architecture, Compass implements a Lucene Directory on top of the database. I think this is the wrong approach. I would leverage the database's built-in support for indexing and implement a Lucene IndexReader instead. The same criticism applies to distributed cache implementations, etc.
I haven't explored this at all, but take a look at LuSql.
Using Solr would be straightforward as well but there'll be some DRY-violations with the Solr schema.xml and your actual database schema. (FYI, Solr does support wildcards, though.)
We are rolling out our first application that uses Solr tonight. With Solr 1.3, they've included the DataImportHandler that allows you to specify your database tables (they call them entities) along with their relationships. Once defined, a simple HTTP request will tirgger an import of your data.
Take a look at the Solr wiki page for DataImportHandler for details.
As introduction:
Brian McCallister wrote a nice blog post: Using Lucene with OJB.