According to this documentation, in neo4j 4.2.X one can create freetext indexes as follows:
CREATE FULLTEXT INDEX my_index
FOR (n:MYNODETYPE) ON EACH (n.label)
Yet when I run this query, I get the following error message:
Invalid input 'I': expected whitespace, comment, '=', node labels, MapLiteral, a parameter, a parameter (old syntax), a relationship pattern, ',', FROM GRAPH, USE GRAPH, CONSTRUCT, LOAD CSV, START, MATCH, UNWIND, MERGE, CREATE UNIQUE, CREATE, SET, DELETE, REMOVE, FOREACH, WITH, CALL, RETURN, UNION, ';' or end of input (line 1, column 17 (offset: 16))
"CREATE FULLTEXT INDEX my_index"
I've seen this related post which had a similar error, but the accepted answer says that the syntax I'm using should be valid in neo4j 4.X. I'm running neo4j 4.2.7, community edition (confirmed by calling dbms.components()).
What am I doing wrong?
I am looking at the docs and they seem a bit different. Try the following:
CREATE FULLTEXT INDEX titlesAndDescriptions FOR (n:MYNODETYPE) ON EACH [n.label]
It seems the above syntax is for Neo4j 4.3+. Syntax for previous versions of Neo4j is as follows:
CALL db.index.fulltext.createNodeIndex("titlesAndDescriptions", ["MyNodeType"], ["label"])
Related
SELECT data FROM users WHERE data.role = "ADMIN"
This query returns an error because of the reserved keyword role from SQL. Same for password.
I have created the index:
CREATE INDEX loginSearchIndex ON users(data.role) USING GSI
(using a ` char is the only way this works. If I do the same in the query, it will not return any results.
For nested objects that don't have any reserved keywords, it works just fine.
Any ideas of how I can escape the reserved keyword when running an N1QL query?
All the query tests are performed in the Query Workbenck
So, after digging around a bit I found how it should be done
Create the index and you can use as many nested fields as you like but using the ` char:
CREATE INDEX loginSearchIndex ON users(data.`role`) USING GSI
Then you run the Query
SELECT data FROM users WHERE data.`role` = "ADMIN"
Works fine
UPDATE:
If you have nested JSON, you can wrap each key in `. Don't forget to add the necessary index
SELECT data FROM users WHERE data.`children`.`rockets`.`elon`.`age` = "48"
I use Neo4j 3.4.0 Community Edition with APOC apoc-3.4.0.1-all.jar
I'm looking for the way how to properly via Cypher/APOC clear manual index.
Right now I'm trying something like that:
CALL apoc.index.relationships('HAS_VALUE_ON', '*:*')
YIELD rel
WITH rel
CALL apoc.index.removeRelationshipByName('HAS_VALUE_ON', rel)
RETURN true
but I don't know how to properly provide the *:* predicate in order to retrieve all of the relationships from the index.
The current query fails with the following error:
Neo.ClientError.Security.Forbidden: Write operations are not allowed
for user 'neo4j' with FULL restricted to READ.
How to properly clear manual index with Cypher/APOC?
I am using Firebird 2.5 and came across a problem that I can not resolve by myself.
There is a statement using UPDATE OR INSERT INTO. I would like to make it use a specific execution plan. But - no matter where I place the PLAN - I get following error message (line number varies with PLAN's position):
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 2, column 5.
plan.
I did not find anything about the usage of PLAN with UPDATE OR INSERT INTO in the corresponding documentation.
Aspects of my question: Is it even possible to use them together? Does this work or is it planned to work in a later version of Firebird? Is there an obvious reason it does not work, that I did not see? Which alternatives exist to circumvent this?
It is not possible to do this in Firebird 2.5 (and also not possible in 3.0). Looking at the parser definition, the PLAN clause is only supported on:
select query specification
searched delete
searched update
For a merge statement it should be possible to specify a plan for the source (if it is a select query), but not for the merge itself. The plan clause is not defined for update or insert (nor is it for insert, for example).
As far as I am aware there is nothing planned to add this to Firebird 4. You should consider adding an improvement ticket in the tracker, but I don't know if this is even possible at all.
I am using OrientDB 2.0.9 with a Java application. I am using graph Java API to create graph instance. I am facing an issue with Lucene index search.
I have entered some data in a vertex and then if I do a Lucene search, I get the result. Then I restarted orientdb server and then same Lucene search doesn't return any data inserted in last server run. Whereas if I do a normal field search without Lucene index, I can see all result.
final OrientGraphFactory gFactory = new OrientGraphFactory("db_path").setupPool(0, 10);
OrientGraph graphDB = gFactory.getTx();
graphDB.setUseLightweightEdges(true);
OrientDynaElementIterable result = (OrientDynaElementIterable) graphDB.command(
new OCommandSQL("select from KnowledgeElement where description LUCENE ?")
).execute(searchText);
I have also tried this with 2.1.4 server.
Some more information which could help: I have created vertex and lucene index by running below commands through console:
CREATE class KnowledgeElement extends V
CREATE property KnowledgeElement.description String
ALTER property KnowledgeElement.description collate ci
CREATE index KnowledgeElement.description on KnowledgeElement (description collate ci) FULLTEXT ENGINE LUCENE
Any help would be highly appreciated. I am unable to get it work and therefore I am forced to replace lucene search by simple like search.
I am still clueless about the problem. Any help is highly appreciated.
I am having an issue executing this query.
SELECT * FROM gob_attachment
WHERE CONTAINS (gob_a_document, 'java') > 0
It's giving me
ORA-29902: error in executing ODCIIndexStart() routine
ORA-20000: Oracle Text error:
ORA-00942: table or view does not exist
29902. 00000 - "error in executing ODCIIndexStart() routine"
*Cause: The execution of ODCIIndexStart routine caused an error.
*Action: Examine the error messages produced by the indextype code and
take appropriate action.
After some googling I've disovered that problem could be in index, but when I looked at the table and index they seemed ok to me.
Create script for index is looking like this
CREATE INDEX FTSI_GOB_A_DOCUMENT
ON GOB_ATTACHMENT (GOB_A_DOCUMENT)
INDEXTYPE IS CTXSYS.CONTEXT;
Only thing which is strange to me is that when I look to Edit Table in Table properties in SQL Developer I can see that Operational Status of index is FAILED. Does anyone know what does it mean?Maybe DB rights?
Also it's working when I use
dbms_lob.instr(gob_a_document, utl_raw.cast_to_raw('java')) > 0
instead of contains
Thanks for any advice
P.S. It's related to my previous question Oracle DBMS_LOB.INSTR and CONTAINS performance
UPDATE
After recreating the index and some playing around, I've disovered that I can execute the query above, but it won't return me anything.
If I try it with CONTAINS(gob_a_document, '%'), the result is 26 rows and don't know by which key the query selected them(at least I didn't find anything obvious, I'll investigate it more). Problem could be in that we are using Oracle 10g and storing DOCX files which are supported from version 11.
"Operational Status of index is FAILED"
Okay, this means your CREATE INDEX statement failed. Did you get an error message? I guess the answer is yes but you missed it. So what you need to do is:
drop the index
re-run the CREATE INDEX statement
if it throws an error, make a note of the reason and fix it
In case it's not obvious, the other statement runs because it's not attempting to use your CONTEXT index. It's doing the search the hard way.
"The thing was that the index was already created in DB,"
No the real thing was the index failed to create properly, hence its status. You could just have rebuilt the index, but it is usually better to fix the underlying cause of failure first. That's why I advised you to drop and recreate. Obviously the original failure was due to some ambient condition which no longer applies.
"Now the query is executed, but it's not giving me any results(0 rows
returned). (and I am sure that it should return like 100 rows) "
So that sounds like you are storing documents in a binary format. What sort of documents? Are they in a supported format? That will depend upon which version of Oracle you're using. For instance, Oracle Text 10g supports up t Word 2003 (i.e. DOC only) whereas Oracle Text 11g supports Word 2007 (i.e. DOCX as well).