We can delete all nodes and relationships by following query.
MATCH (n) OPTIONAL MATCH (n)-[r]-() DELETE n,r
But newly created node get internal id as ({last node internal id} + 1) . It doesn't reset to zero.
How can we reset neo4j database such as newly created node will get id as 0?
From 2.3, we can delete all nodes with relationships,
MATCH (n)
DETACH DELETE n
Shut down your Neo4j server, do a rm -rf data/graph.db and start up the server again. This procedure completely wipes your data, so handle with care.
run both commands.
match (a) -[r] -> () delete a, r
above command will delete all nodes with relationships.
then run ,
match (a) delete a
and it will delete nodes that have no relationships.
Dealing with multiple databases.
According to Neo4j manage multiple databases documentation:
One final administrative difference is how to completely clean out one database without impacting the entire instance with multiple databases. When dealing with a single instance and single database approach, users can delete the entire instance and start fresh. However, with multiple databases, we cannot do that unless we are comfortable losing everything from our other databases in that instance.
The approach is similar to other DBMSs where we can drop and recreate the database, but retain everything else. Cypher’s command for this is CREATE OR REPLACE DATABASE <name>. This will create the database (if it does not already exist) or replace an existing database with a clean one.
When neo4j is initiated, it is possible to access two databases, a system database and a default (neo4j) database. To clear/reset neo4j database:
1 - Switch to system database:
:use system
2 - Show all databases created with the instance:
SHOW DATABASES
3 - Run the command to clear the database.
CREATE OR REPLACE DATABASE <name>
In my experience, there are two ways to reset a Neo4j database, depending on what you need.
Method 1: Simply delete all nodes/relationships/indexes/constraints
In Neo4j Browser, or in Py2neo with graph.run() (link).
# All nodes and relationships.
MATCH (n) DETACH DELETE n
# All indexes and constraints.
CALL apoc.schema.assert({},{},true) YIELD label, key RETURN *
However, despite being convenient, this approach is not suitable in case of using command neo4j-admin.bat import for BULK import, i.e. ideal for importing millions of nodes at once quickly.
Method 2: Reset database for BULK Import Tool
It's not possible to BULK import when the database is not empty. I tried the above method, but still received the error:
Import error: C:\Users\[username]\AppData\Local\Neo4j\Relate\Data\dbmss\dbms-dd16c384-78c5-4c21-94f3-b0e63e6c4e06\data\databases\neo4j already contains data, cannot do import here
Caused by:C:\Users\[username]\AppData\Local\Neo4j\Relate\Data\dbmss\dbms-dd16c384-78c5-4c21-94f3-b0e63e6c4e06\data\databases\neo4j already contains data, cannot do import here
java.lang.IllegalStateException: C:\Users\[username]\AppData\Local\Neo4j\Relate\Data\dbmss\dbms-dd16c384-78c5-4c21-94f3-b0e63e6c4e06\data\databases\neo4j already contains data, cannot do import here
To tackle this issue, I deleted the following folders:
c:\Users\[username]\AppData\Local\Neo4j\Relate\Data\dbmss\dbms-dd16c384-78c5-4c21-94f3-b0e63e6c4e06\data\databases\neo4j
and
c:\Users\[username]\AppData\Local\Neo4j\Relate\Data\dbmss\dbms-dd16c384-78c5-4c21-94f3-b0e63e6c4e06\data\transactions\neo4j
Then carried out the Import command:
"C:\Users\[username]\AppData\Local\Neo4j\Relate\Data\dbmss\dbms-dd16c384-78c5-4c21-94f3-b0e63e6c4e06\bin\neo4j-admin.bat" import --database=neo4j --multiline-fields=true --nodes=node_ABC.csv --nodes=node_XYZ.csv relationships=relationship_LMN.csv --relationships=relationship_UIO.csv
Start the Neo4j database. In Neo4j Desktop, the labels and relationships should now be recognized.
Notice that the database I deleted (neo4j) and the database I imported to are the same.
This worked for me with ver. 4.3.2 of the community editition:
Stop the server
cd <neo home>
rm -Rf data/databases/* data/transactions/*
Restart the server
Now you've again the system and the neo4j DBs. The command above deletes the system DB too, and that seems necessary, since deleting a regular DB only (which, in the community edition can only be 'neo4j') makes the metadata in the system DB inconsistent and you start seeing errors.
data/dbms seems to contain the user credentials and you can keep it if you want to keep existing users (else, you'll go back to the default neo4j/test user).
The recommended method is to use the DROP or CREATE Cypher commands, however, these are available in the enterprise edition only (I think it's a shame that a basic feature like this is part of their premium offer, but that's it).
This command deletes everything but requires apoc to be installed :
CALL apoc.periodic.iterate('MATCH (n) RETURN n', 'DETACH DELETE n', {batchSize:1000})
If you are using it on a docker container, you can do
docker-compose rm -f -s -v myNeo4jService
Since neo4j only runs current database specified in the conf file, an easy way to start a new and clean db is to change the current database in the neo4j.conf file and then restart neo4j server.
dbms.active_database=graph.db --> dbms.active_database=graph2.db
Some might argue that the database name is changed. But as of this writing [2018-12], neo4j doesn't support multiple database instances. There is no need for us to differentiate between databases, thus the name of the database is not used in our code.
You can clear/truncate the database with the command below:
MATCH (n) DETACH DELETE n
What this command does is, it matches all the nodes in the database, then detaches all the relationships the matched nodes have and finally deleting the nodes themselves.
Related
I'm using a postgresql (9.6) database in my project which is currently in development stage.
For production I want to use an exact copy/mirror of the database-cluster with a slightly different name.
I am aware of the fact that I can make a backup and restore it under a different cluster-name, but is there something like a mirror function via the psql client or pgAdmin (v.4) that mirrors all my schemas and tables and puts it in a new clustername?
In PostgreSQL you can use any existing database (which needs to be idle in order for this to work) on the server as a template when you want to create a new database with that content. You can use the following SQL statement:
CREATE DATABASE newdb WITH TEMPLATE someDbName OWNER dbuser;
But you need to make sure no user is currently connected or using that database - otherwise you will get following error.
ERROR: source database "someDbName" is being accessed by other users
Hope that helped ;)
I'm a beginner in PostgreSQL. I wonder why the \l command in psql shows databases template0 and template1.
I searched the web but unfortunately didn't find the right resources. But I did find that after removing both (template0 & template1) we can't create new databases any more.
As the names indicate, those are template databases for creating new databases.
template1 is the one used by default. You can alter / add / remove objects there to affect every newly created DB. CREATE DATABASE basically makes a copy of it on the file level (very fast) to create a new instance.
template0 starts out being the same and should never be changed - to provide a virgin template with original settings.
Their role is described in detail in the chapter "Template Databases" in the manual.
But you can use any database of the same cluster as template with the TEMPLATE keyword - as long as there are no open connections to it. This is useful to populate new databases quickly. See:
How to clone a test database from a production one in one single action?
Shell script to execute pgsql commands in files
Truncating all tables in a Postgres database
First forgive me for my English. It is a little bad. Second forgive my ignorance, i'm newiest in postgres
I'm having trouble when I try to up a backup database on another database. I need to dump the database just to get one table, but I only have the files that was in /var/lib/pgsql/data/base/
Here what I try:
I create a database named "test" with OID 227763 so I put the files of the old database to this new database with another OID. I fix the folder and files permissions, but when I log into "test" and run select * from pg_tables; the tables does not appears to me. And when I try to create the table on PhpPgAdmin, I got
ERROR: relation already exists
I'm trying to do this because I need to know which of this files is the table that i want. I will log into database and run SELECT oid,* from pg_class; to get the OID.
I found the old OID database in /var/lib/pgsql/data/global/pg_database
If anyone can help me, I thank you.
There are many ways to backup and restore an entire database or a single table. It sounds like you need to be using pgDump instead of working on individual files. A file level copy is likely to corrupt your database if not in backup mode and if not copying the entire thing + archive logs.
If you MUST copy it by files, make sure the database is shut down for maximum safety.
For me, if I had one table to backup, I'd use pg_dump
pg_dump -U {user-name} {source_db} -f {dumpfilename.sql}
you can use the -t flag to list a single table if you like.
I use the doctrine migrations bundle to track changes in my database structure. I would like to ensure that when I'm deploying / adding a new server for my application that:
(A) the database schema is up to date (doctrine:migrations:migrate)
(B) the database always contains a pre-defined set of data
For (B) a good example is roles. I want a certain set of roles to always be present. I realize it is possible with database migrations, but I don't like the idea of mixing schema changes with data changes. Also if I use MySql migrations I would have to create a equivalent Sqlite migration for my test database.
Another option I'm aware of is data fixtures. However from reading the documentation I get the feeling that fixtures are more for loading test data. Also if I changed a role name I don't know how that would be updated using fixtures (since they either delete all data in the database before loading or append to it). If I use append then unique keys would also be a problem.
I'm considering creating some sort of command that takes a set of configuration files and ensures that certain tables are always in a consistent state matching the config files - but if another option exists I'd like to use it of course.
What is the best way to handle loading and managing required data into a database?
If you're using Doctrine Migrations, you can generate initial migration with whole database schema, then you should generate migrations (doctrine:migrations:generate or doctrine:migrations:diff) for all changes that are made in database structure AND also add there queries that will migrate existing data.
Fixtures are designed to pre-populate data (with doctrine:fixtures:load) and, in my opinion, they should be kept up-to-date with latest database schema and executed after doctrine:migrations:migrate / doctrine:schema:create.
So finally:
Create base migration with initial database schema (instead of executing doctrine:schema:create just generate migration file and migrate it)
Create new migrations for each database schema change AND for migrating existing data (such as role name changing)
Keep fixtures up-to-date with latest schema (you can use --append option and only update fixtures instead of deleting all database data first)
Then, when deploying new instance you can run doctrine:schema:create, then doctrine:migrations:version --add --all --no-interaction (mark all migrations as migrated, because you have already created latest schema) and doctrine:fixtures:load which will populate data to the database (also latest version, so data migrations from Doctrine migrations files are not required).
Note: Existing instances should NOT use doctrine:schema:update, but only doctrine:migrations:migrate. In our app we even block usage of this command, in app/console:
use Symfony\Component\Console\Output\ConsoleOutput;
use Symfony\Component\Console\Helper\FormatterHelper;
// Deny using doctrine:schema:update command
if(in_array(trim($input->getFirstArgument()), ['doctrine:schema:update'])) {
$formatter = new FormatterHelper();
$output = new ConsoleOutput(ConsoleOutput::VERBOSITY_NORMAL, true);
$formattedBlock = $formatter->formatBlock(['[[ WARNING! ]]', 'You should not use this command! Use doctrine:migrations:migrate instead!'], 'error', true);
$output->writeln($formattedBlock);
die();
}
This is what I figured out from my experience. Hope you will find it useful :-)
I'm struggling to find a suitable solution to this. I have a fairly large SQL Server 2008 Express database containing 60+ tables (many with key constraints) and a whole bunch of data.
I need to essentially copy all of these tables and the data and the constraints exactly from one database to another. I'm basically duplicating website A - to produce an exact copy (website B) on a different domain so we end up with two completely identical websites running in parallel, each with their own identical database to begin with.
Database A is up and running on website A. Database B is set up and has it's own user. I just need to get the tables and the data intact from A to B. I can them modify my web.config connection to use the log-in credentials for database B and it should work.
I've tried backing up database A and restoring to database B via Management Studio Express, but it tells me:
System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing 'database-B' database.
(Microsoft.SqlServer.Smo)
I've also tried right clicking database A in Management Studio Express and going to Tasks > Generate scripts. But when I do this and run the SQL scripts on database B I get a whole load of errors to do with foreign keys etc as it imports the content. It seems like it's doing the right thing, but can't handle the different keys/relationships.
So does anyone know of a simple, sure-fire way of getting my data 100% exact and intact from database A to database B?
I think I used SQL Server Database Publishing Wizard to do something like this about 5 years ago, but that product seems to be defunct now - I tried to install it and it wanted me to regress my version of SQL Server to 2005, so I'm not going there!
Don't use the UI for this. If you're not familiar with the various aspects of BACKUP/RESTORE the UI is just going to lead you down the wrong path for a lot of options. The simplest backup command would be:
BACKUP DATABASE dbname TO DISK = 'C:\some folder\dbname.bak' WITH INIT;
Now to restore this as a different database, you need to know the file names because it will try to put the same files in the same place. So if you run the following:
EXEC dbname.dbo.sp_helpfile;
You should see output that contains the names and paths of the data and log files. When you construct your restore, you'll need to use these, but replace the paths with the name of the new database, e.g.:
RESTORE DATABASE newname FROM DISK = 'C\some folder\dbname.bak'
WITH MOVE 'dbname' TO 'C:\path_from_sp_helpfile_output\newname_data.mdf',
MOVE 'dbname_log' TO 'C:\path_from_sp_helpfile_output\newname_log.ldf';
You'll have to replace dbname and newname with your actual database names, and also some folder and C:\path_from_sp_helpfile_output\ with your actual paths. I can't get more specific in my answer unless I know what those are.
** EDIT **
Here is a full repro, which works completely fine for me:
CREATE DATABASE [DB-A];
GO
EXEC [DB-A].dbo.sp_helpfile;
Partial results:
name fileid filename
-------- ------ ---------------------------------
DB-A 1 C:\Program Files\...\DB-A.mdf
DB-A_log 2 C:\Program Files\...\DB-A_log.ldf
Now I run the backup:
BACKUP DATABASE [DB-A] TO DISK = 'C:\dev\DB-A.bak' WITH INIT;
Of course if the clone target (in this case DB-B) already exists, you'll want to drop it:
USE [master];
GO
IF DB_ID('DB-B') IS NOT NULL
BEGIN
ALTER DATABASE [DB-B] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [DB-B];
END
GO
Now this restore will run successfully:
RESTORE DATABASE [DB-B] FROM DISK = 'C:\dev\DB-A.bak'
WITH MOVE 'DB-A' TO 'C:\Program Files\...\DB-B.mdf',
MOVE 'DB-A_log' TO 'C:\Program Files\...\DB-B_log.ldf';
If you are getting errors about the contents of the BAK file, then I suggest you validate that you really are generating a new file and that you are pointing to the right file in your RESTORE command. Please try the above and let me know if it works, and try to pinpoint any part of the process that you're doing differently.
I realize this is an old question, but I was facing the same problem and I found that the UI was easier and faster than creating scripts to do this.
I believe Dan's problem was that he created the new database first and then tried to restore another database into it. I tried this as well and got the same error. The trick is to not create the database first and name the database during the "Restore Database" process.
The following article is somewhat useful in guiding you through the process:
http://msdn.microsoft.com/en-us/library/ms186390(v=sql.105).aspx