I'd like to normalize my repository. I've got a bunch of identical nodes - identical properties and identical child nodes with their identical properties. I'd like to have just one node that defines the properties and children and have the rest just reference it, thereby eliminating a bunch of redundant nodes.
Is there some property that I can add to a node to make it a duplicate of another without having to actually copy it, like a Unix symbolic link?
Have you looked at the x-ref component? It creates a node that points to the original node & renders the original node instead.
Related
I am trying to simulate a file system using Neo4j, Cypher, and Python(Py2Neo).
I have created the data model as shown in the following screenshot.
Type=0 means folder and type=1 means file.
.
.
I am implementing functions like Copy, Move etc for files/folders.
Move functions look simple, I can create a new relationship and delete the old one. But copying files/folders need to copy the sub-graph.
How can I copy the sub-graph?
I am creating a python module so trying to avoid apoc.
Even though you're trying to avoid APOC, it already has this feature implemented in the most recent release: apoc.refactor.cloneSubgraph()
For a non-APOC approach you'll need to accomplish the following:
MATCH to distinct nodes and relationships that make up the subgraph you want to clone. Having a separate list for each will make this easier to process.
Clone the nodes, and get a way to map from the original node to the cloned node.
Process the relationships, finding the start and end nodes, and following the mapping to the cloned nodes, then create the same relationship type using the cloned nodes for your start and end nodes of the relationship, then copy properties from the original relationship. This way you don't have any relationships to the originals, just the clones.
Determine which nodes you want to reanchor (you probably don't want to clone the original), and for any relationship that goes to/from this node, create it (via step 3) to the node you want to use as the new anchor (for example, the new :File which should be the parent of the cloned directory tree).
All this is tough to do in Cypher (steps 3 and 4 in particular), thus the reason all this was encapsulated in apoc.refactor.cloneSubgraph().
I have a nested tree stored in Neo4j. Where each node can have a (n)-[:CHILD]->(c) relationship with other nodes. Allowing you to query the entire tree from a given node down with MATCH (n)-[c:CHILD*]-(m).
What I am having trouble with, is figuring out how to store a path that a user takes as they walk through a tree. For instance a query to return the path would be (user)-[:USER_PATH*]->(node).
However the path has to remain along the lines of :CHILD relationships, it cannot jump outside of its branch. A user path cannot jump from the leaf of one branch to a leaf of another branch, without first retracting its way back up the path it came from until it finds a fork that will walk down to it.
Also I do not think shortest path will work, because its not the shortest path I want, I want the users actual path. But it should disregard relationships that were abandoned as the user backed out of any branches. It should not be leaving around dead paths.
How would I be able to update the graph after each node is walked to so these rules stay in tact??
It can be assumed that in drilling down into a new branch, it can only step through to one more set of siblings. However all branches it came through are still open, so their siblings can be selected.
Best I can figure is that it needs to:
"prefer" walking the :USER_PATH relationships as long as it can
until it needs to break that path to get to the new node
at which point it creates any new relationships
then delete any old relationships that are no longer on that path
I have no idea how to accomplish that though.
I have spent a ton of time in trial and error and googling to no avail.
Thanks in advance!
Given the image below:
red node = User
green nodes = A valid node to be a new "target"
blue nodes = invalid target node
So if you were to back out of the leaf node it is in currently, it would delete that final :RATIONAL_PATH relation in the chain.
Also the path should adjust to any of the green nodes that were selected, but keeping the existing :RATIONAL_PATH in tact for as far as possible.
Personally I think removing the existing path and creating a new one with shortestPath() is probably the best way to go. The cost of reusing the existing path and performing cleanup is often going to be higher and more complex than simply starting over.
Otherwise, the approach to take would be to match down to the last node of your path, and then perform a shortestPath() to the new node, and create your path.
And then we'd have to perform cleanup. This would probably involve matching all paths along :RATIONAL_PATH relationships to the end node resulting in a group of paths. The one with the shortest distance is going to be the one we keep. We'd need to collect those relationships, collect the other relationships of other paths that are no longer valid, do some set subtraction to get the relationships not used in the shortest path, and deleting them.
That's quite a bit of work that should probably be avoided.
I have pretrained network and I'm trying to get just a part of it (subgraph) tf graph along with variables and saver object.
this is how I'm doing it:
subgraph = tf.graph_util.extract_sub_graph(default_graph, list of nodes to preserve)
tf.reset_default_graph()
tf.import_graph_def(subgraph)
This however removes all variables (when I call reset_default_graph). Even If I explicitely add the operation nodes for variables (only the "variable" type operations) into the "list of nodes to preserve".
How can I preserve subgraph of larger graph while preserving values of variables?
Is it a matter of addition some new nodes to "preserve list"?
The relation between graph nodes and variables is still unclear to me and tutorial merely mentions that creation of variable creates some operations (nodes) in the graph.
I think what you are doing looks right. As you said, a Variable is a simply an operation (a node in graph) that outputs a tensor of certain values. You should be able to add Variable nodes to the list to preserve them, as you have been already doing. Could you use print(sess.graph_def) to make sure the names you provided are correct?
I recently discovered that a race condition exists when executing concurrent MERGE statements. Specifically, duplicate nodes can be created in the scenario where a node is created after the MATCH step but before the CREATE step of a given MERGE.
This can be worked around in some instances using unique constraints on the merged nodes; however, this falls short in scenarios where:
There is no single unique property to enforce (e.g. pairs of properties need to be unique but individual ones don't).
Trying to merge relationships and paths.
Does using CREATE UNIQUE solve this problem (or do the same pitfalls exist)? If so, is it the only option? It feels like the usefulness of MERGE is fairly heavily diminished when it effectively can't guarantee the uniqueness of the path or node being merged...
When MERGE statements are executed concurrently, these situations may occur. Basically, each transaction gets a view of the graph at the first point of reading, and won't see updates made after that point (with some variations). The main exception to this are uniquely constrained nodes, where Neo4j will initialise a fresh reader from the index when reading, regardless of what was previously read in the transaction.
A workaround could be to create a 'dummy' property and a unique constraint on it and one of the node labels. In Neo4j 2.2.5, this should work to get around your problem.
I need to write batch importing utility for my Neo4j database but I don't want to lose the repository feature of SDN. To achieve this goal I want to insert such nodes that can be still queried using auto generated repository methods.
I inserted some nodes to my database and I looked at their properties and labels to see how they are set and I noticed that SDN inserted nodes have two labels. For example nodes representing class SomeClass have labels: ["_SomeClass", "SomeClass"]. My question is: why set two, almost identical labels for each node?
Oh that's actually simple. We somehow have to note if the current node is of type SomeClass, which we do by prepending the "_". As there are labels added for each super-type you need to differentiate what the actual type of the node in Spring Data Neo4j is.
So you could have: _Developer, Developer, Employee, Person for a class hierarchy from Person down to Developer. And then there could be additional labels for interfaces.
When you now do: DeveloperRepository.findAll() then you only want those with _Developer back, not ones that derived from Developer.