Hi, Mattias. I'll definitely give it a try.
Ultimately, I'd like to achieve the following scenario (and maybe you can give us some guidance on how to implement it): As a use case: we want to index the node associated with a "collaboration entry" (that has a timestamp, tag(s), location, textual content, and potentially some numeric values as properties) on a combination of what is currently many different types of indexes in Neo - fulltext, timeline, spatial, and "plain" (key/value field(s)). We'd like to search/query on any combination of those elements. We've been considering a few options: - use relationships (that wouldn't meet our performance/concurrency requirements) - use the current index framework with separate indexes, query multiple times, and do the set comparison/intersection in our code - bypass Neo's indexing model altogether and go directly to Lucene, though we'd lose the transaction capabilities - hack the Neo code for the various Lucene index implementations and create our own "composite index" index type that supports fulltext fields, geospatial fields, simple data types (string, number, boolean), timeline, and multi-valued fields I like option #4, but we'd definitely need some help and input to build it in a way that wasn't too fragile from version to version of Neo. I think it is a capability that would be broadly useful for a lot of Neo users, though, and would fit nicely with some of the work Anders is doing in a Neo query language/syntax. I do think the ability to have more control at the "field" level could lead to some cool capabilities and significant optimizations both in storage and retrieval. I also think you've managed to work around the transactioning issues, so it would be foolish to re-invent the wheel there. The basic idea would be a composite index that perhaps had a new "add" method which accepted a Field definition instead of just a simple string field name. The Lucene index implementation could leverage this to exploit a lot of the power of Lucene to meet the overall goal of a very flexible indexing/query subsystem for Neo4J. Additionally, the Field definition for full-text fields could have an analyzer associated with it, rather than an Analyzer at the index level only. If you would be up for it, maybe we come over to Sweden for a couple days and hack #4 together, or we could do it "virtually"? Thoughts? Rick -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mattias Persson Sent: Thursday, May 12, 2011 3:55 AM To: Neo4j user discussions Subject: Re: [Neo4j] Index Framework - Query Question Could you perhaps create an index with a custom Analyzer which treats titles as fulltext and others as non-analyzed? 2011/5/11 Rick Bullotta <[email protected]> > Is there currently any way to have a composite index consisting of fulltext > and non-analyzed (simple fields), and to query them in a single query > statement? e.g. : title:Reloaded AND year:1999 > > In this case, I'd be using a Lucene Analyzer on the title, but indexing the > primitive types without using the analyzer/norms/etc...I know how to do it > with Lucene directly, but not clear if it can be done w/Neo4J. > > Thanks! > > Rick > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
