You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have to use Lucene to support search on the in-memory store implementations. My thinking here is:
We might as well reuse this code rather than having equivalent code that works with neo4j
neo4j indexes are only on nodes xor relationships, not both, whereas Lucene can have index any document. Ideally we want all search result types (edge, edge label, node, node label, source) in the same index, so they can be scored relative to each other and our GraphQL search() only does one search on the index.
neo4j doesn't expose other features of Lucene, such as drill-down faceted search. We have to implement equivalents by doing fulltext search and then traversing the graph with Cypher.
The main advantage of using neo4j's Lucene is that it's kept up-to-date as the underlying neo4j graph database changes. But since our graph is effectively write-once this isn't that big of a deal.
We may want to use Lucene's Java API directly instead of the lucen4js Scala wrapper, which doesn't completely reflect the underlying Java.
The text was updated successfully, but these errors were encountered:
Follow-up from #224.
We have to use Lucene to support search on the in-memory store implementations. My thinking here is:
The main advantage of using neo4j's Lucene is that it's kept up-to-date as the underlying neo4j graph database changes. But since our graph is effectively write-once this isn't that big of a deal.
We may want to use Lucene's Java API directly instead of the lucen4js Scala wrapper, which doesn't completely reflect the underlying Java.
The text was updated successfully, but these errors were encountered: