Hi!
We are upgrading our neo4j dbs from neo4j 3.5 to 4.4 using dump and load CLI commands. We are currently using the community edition.
While the migration process from 3.5 -> 4.0 -> 4.1 -> 4.2 -> 4.3 -> 4.4 ends successfully, the nodes' IDs change on each migration, is there any config key that I could add to keep them the same on each migration?
Thanks!
When we're talking about store format upgrades, I don't believe we have a way to keep the internal node ids stable.
And in any case, you should not be depending on these to remain the same long-term, both because of this (and any neo4j-admin copy usage may similarly change internal ids) and also because of id reuse. When a node / property / element is deleted, its internal id will become eligible for reuse for new entities you create.
graph internal ids therefore should not be preserved for longterm use. You could use them between two queries that execute within a relatively short time of each other (find the nodes to process in one query, return their internal ids, then process in the immediately following query) or within the same query, but even then it would be better to rely upon indexed properties instead of the internal graph id.
Oh, that's bad for us... we were using the IDs as foreign keys on another database.
Is there any documentation about this? I searched for some info about node IDs without success.
It seems like the way we should move forward is to create the IDs ourselves.
Thanks for your answer!
It's recommended to use your own property (or properties) as the key for nodes, that way you can either index them (if they are not unique) or create unique constraints for them (if they are unique) or node keys for them (uniqueness + existence constraints). The constraints mentioned here will also create an index for them for quick lookup by the property / properties.
Documentation about the id() function, and the elementId() function (a replacement for id(), but still subject to some of the same limitations and warnings) can be found here:
and
The relevant warnings are these:
Outside of the scope of a single transaction, no guarantees are given about the mapping between ID values and elements.
and more specifically
Neo4j reuses its internal IDs when nodes and relationships are deleted. This means that applications using, and relying on internal Neo4j IDs, are brittle or at risk of making mistakes. It is therefore recommended to rather use application-generated IDs.
And as I previously noted, any kind of node compaction, such as when using neo4j-admin database copy or migrate, can rebuild the database and in the process the ids may change.