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 OrientDB and the gremlin console that comes with.
I am trying to search a pattern in text property. I have Email vertices with ebodyText property. The problem is that the result of querying with SQL like command and Gremlin language is quite different.
If I use SQL like query such as:
select count(*) from Email where eBodyText like '%Syria%'
it returns 24.
But if I query in gremlin console such as:
g.V.has('eBodyText').filter{it.eBodyText.matches('.*Syria.*')}.count()
it returns none.
Same queries with a different keyword 'memo' returns 161 by SQL but 20 by gremlin.
Why does this behave like this? Is there a problem with the syntax of gremlin command? Is there a better way to search text in gremlin?
I guess there might be a problem of setting properties in the upload script which uses python driver 'pyorient'.
Python script used to upload the dataset
Thanks for your help.
I tried with 2.1.15 and I had no problem.
These are the records.
EDITED
I added some vertexes to my DB and now the count() is 11
QUERY:
g.V.has('eBodyText').filter{it.eBodyText.contains('Syria')}.count()
OUTPUT:
==>11
Hope it helps.
I have 29 separate tables of council address data with identical field headers and thousands of entries. I am trying to find an address based on property id that should appear in at least one of the tables. I have been trying to use a union query;
SELECT "ST_NO_FROM","STREET","ST_TYPE"
FROM "list_address_points_break_o_day"
WHERE "PID" = 6413877
UNION
SELECT "ST_NO_FROM","STREET","ST_TYPE"
FROM "list_address_points_brighton"
WHERE "PID" = 6413877
Base is crashing every time I try to use this query and requires recovery. Does anyone have any idea why this is happening?
Be sure to use a split database setup and avoid embedded databases. From the link:
When the
file is "closed," the latest contents are repackaged into a single
zip-archive by *Office. This re-packaging process is problematic and
commonly leads to file-corruption...
So it's best to avoid these 'embedded database' files whenever
possible. This means avoiding the wizard dubbed 'Create a new
database' in Base.
HSQLDB (either 1.8 or a newer 2.x version) should be stable enough to handle the data. If the needs are very complex then a full-scale RDBMS such as MySQL could be used instead.
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 have an Access application that use the classical front-end/back-end approach. Yesterday, the backend got corrupted for a reason I don't know. So I opened the backend with Access 2003 and access asked me if I wanted to repair the file, I said yes and it seemed to work.
I can open the database see the tables contents and run most of the queries.
However there is an access query that doesn't work with a specific where clause.
Example :
// This works in the original DB, but not in the compacted one :
SELECT a, b, c
FROM tbl1 INNER JOIN tbl2 ON tbl1.d = tbl2.d
WHERE e = 3 AND tbl2.f = 1;
// This works in both the original and the compacted one :
SELECT a, b, c
FROM tbl1 INNER JOIN tbl2 ON tbl1.d = tbl2.d
WHERE e = 3;
When I try to run the queries, nothing happens. The access process start to use most of the CPU and the GUI stop responding. If I run the query from the query editor, I can use Ctrl+Break to stop the execution. I tried to give the query lot of time and it didn't help.
I've checked the execution plan in showplan.out and it seems correct (at least it should not takes forever to execute)
I tried to compact the DB again. I tried to import the tables in a new DB. I even tried to import the tables and their data in a mdb file that was in a now good state (from a backup).
Anyone have an idea?
Sounds like an index was corrupted and when that happens, it's dropped during the compact. Check for a system table called MSysCompactErrors -- you'll have to show hidden objects and/or system objects in Tools | Options | VIEW.
Never compact a Jet MDB without making a backup beforehand. Because of that rule, the COMPACT ON CLOSE function is completely useless, as it's not cancellable, so you always make sure it's turned off in all MDBs.
I don't know what type of meta data Access brings along when it imports a table from one database into another one. If the meta data is corrupted, importing the table to another database wouldn't necessarily resolve the problem. If practical, you might try creating the tables from scratch in a brand new database and then just exporting and importing (or copying and paste appending) the data into the new database.
I've never seen a table get corrupted like this in such a small database, although with Access anything is possible. Could there be something wrong with the data?
I'd try recreating the query fresh (new name, etc.), and see what happens.
You could even try copying it (even within the same DB or to a brand new one). If that works, the worst case scenario is you have to copy all the objects across to a new DB.
Is there an index on the field tbl2.f?
Also try going into that table in datasheet view, sort tbl2.f in ascending sequence and see if there is anything really strange in the first or last records.
Do you have access to a SQL Server installation? You could use the Upsizing Wizard under the Tools -> Database Utilities menu to copy the data to SQL Server, and see if you get the same problem there.