Closed (fixed)
Project:
Neo4J Connector
Version:
8.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
11 Apr 2014 at 20:16 UTC
Updated:
23 Mar 2017 at 16:14 UTC
Jump to comment: Most recent
On my last presentation I've got some really great feedback. One of them was to make the module compatible with SearchAPI - as it has already a rich feature support. I'm using SearchAPI for a long time - however not too familiar with the API and I'm still wondering if the graph concept is close to what SearchAPI is doing.
Pros:
- support for indexing and UI
- support for facets
- support for autocomplete
- etc
Cons:
- the idea is different: search api is to look up content by given filter criteria - meanwhile graph is to match a pattern (different from traditional filters) and return nodes, properties or paths
- in graph search you often has to know your starter node already (FOAF graphs starts from your user account, for example)
What do you think? Possible or not? Make sense or not?
Comments
Comment #1
mihai_brb commented@itarato, nice initiative!
This would be perfect, because often you will use information from context such as the current logged in user, or the entity that is being displayed.
Also integrating with Search API will give you the ability to filter what is being added to the graph. Maybe not all entities or their properties are relevant in a graph context.
Mihai
Comment #2
itarato commentedHi Mihai,
Thank you for your feedback. I just took a quick look at the SearchAPI interfaces - to be honest I can imagine an implementation, however not entirely convinced with the whole feature. One important point of the SearchAPI is that you can use the same search facility independently of the backend implementation. So it doesn't matter if you have Solr or simple DB as a backend. For graphs you have some special features, such as defining the hops the query can do (distance), or the return type (path).
Hmm hmm. Actually that might not be a big problem.
Can you tell me some examples, please, in your scenario how would it work? From the UI to the returned value.
I might start doing a prototype and see how well it fits actually.
In anyways, thank you for the support ;)
Comment #3
miro_dietikerWe recently had the Drupal 8 Search API sprint in our office and Search API evolved into its next level.
Our discussion also brought us into direction of writing a backend for neo4j.
#2286293: Support for neo4j backend?
I pinged the maintainer for some direct feedback.
I finally found this issue here! :-)
I do think that Search API is the right tool, or at least the right scope to discuss about match / mismatch and possibly design the final Drupal 8 interfaces of Search API right! Thus it's time that you review it and join the discussion!
At least for the whole indexing process it is a great help.
If it's a good fit for searching needs to be decided. You might want to provide some custom features on top of search API. But you can also natively talk to neo4j to query.
It would be awesome to start porting the indexing. Then we can look further.
Comment #4
miro_dietikerAdd relationship.
Comment #5
itarato commentedHi Miro,
Cool :) I'm happy there is an active discussion about it.
It does make sense to start with the index part. Let me take a look at the current state and how could we make the necessary change to make the indexing work togethet. Thank you very much for the heads up!
Comment #6
miro_dietikerI see there's an 8.x dev branch + release.
Peter, could you please update this issue about the 8.x status? Or possibly open a different issue about it?
Comment #7
itarato commentedThe interesting branch is 8.x-1.x-search_api where I tried to use SearchAPI. On the minimal level it was working fine, indexing took the items and put it in the graph database. However I've found couple of difficulties when tried to build up related nodes and relationships. Let me explain them.
The way I imagine - and I've put a lot of thinking there, this seemed the way to go - is you mark an entity for indexing. When the indexer sees that there is a new entity to index, it loads information about:
- labels (it's a Neo4J think, basically a type name, such as: entity:node for distinction)
- properties (the most important properties that should be on the graph node (these are not Drupal field values)
- related graph nodes (these are coming from Drupal fields and maybe entity properties) - meaning that these items will be new graph nodes
First, that's a difference compare to normal indexing - that here one indexed item can create multiple graph nodes, however the index still connects to the main graph node. The related graph nodes might be used by other nodes. For example Field-Tag-[Business] is a graph node representing a Drupal term can be connected to several graph nodes representing Drupal nodes. Anyways - this wouldn't be much of a problem now.
The tricky part is find the fields that you need the use for graph node relationships. SearchAPI has a field selection API where you can mark the indexed fields. During the index procedure you need to get these items and create a unique index for the graph db in order to be able to identify them at any given time. This part was a bit tricky and I didn't have enough time to work it out. It seems SearchAPI keeps the trail of field names, types in a string (such as: "entity:node|field_tags") and parsing that string was a little bit messy.
Still working on it sometimes but at this point I less think it's a fitting model to traditional relational indexing.
Comment #8
itarato commentedAdded the Search API integration to 8.x-2.x, indexing can pull entities with field values to graph nodes and graph node properties. A mapping processor can define relationships between field values (references) and entities to create connection between graph nodes.
No search query implementation yet, not convinced if that should happen as the query interface is not quite graph friendly.
Comment #9
itarato commented