Better Know APOC #2: apoc.graph.fromDB

By Charlotte

A rubbish picture that really doesn't represent anything - but you could say 'apoc.graph.fromDB' - honestly - you're not missing anything here

Neo4j.Version 3.0.0
APOC Version 3.3.0.1

If you haven’t already, please have a look at the intro post to this series, it’ll cover stuff which I’m not going to go into on this.

Back at the beginning of this series (if you can remember that far!) I talked about using apoc.export.csv.* – and I showed that an example of using apoc.export.csv.graph that took in a graph – and to get that graph – I used apoc.graph.fromDB. I also said I wasn’t going to cover it in that post – and I didn’t. Time to rectify that lack of knowledge!

What does it do?

apoc.graph.fromDB takes your existing DB and creates a whole new virtual graph for your use later on – we’ve seen it in use in episode 1 – the phantom men… sorry – apoc.export.csv.graph, but a virtual graph can be used in other procedures . This particular instance is a hefty ‘catch all’ version – maybe overkill for most needs – but equally – maybe exactly what you’re after (if you’re after dumping your DB).

Setup – Neo4j.conf

dbms.security.procedures.unrestricted=apoc.graph.fromDB

Ins and Outs

Calling apoc.help(‘apoc.graph.fromDB’) get’s us:

Inputs (name :: STRING?, properties :: MAP?) ::
Outputs (graph :: MAP?)

Inputs

Only two this time, and I reckon you can pretty much ignore them, so that’s a win?!

Name

This is as simple as it seems – just the name – I’m going to be honest here – I really am not sure what this is for – you can access it later on though. I’m pretty sure this is a hangover from the other apoc.graph.from* methods – where it makes more sense as a distinguisher – but for this procedure – as we’re just exporting the whole db, go for whatever you like.

Properties

Just a collection of key/values – accessible after the procedure has executed – but otherwise not used by the procedure.

Outputs

Just the one! Amazeballs!

Graph

This is what you need to YIELD to use the procedure (the examples will cover this) – to access the name you use:

RETURN graph.name

To get your properties it’s:

RETURN graph.properties.<your-property-here>

Examples

Assuming as always that you have the Movies DB setup and ready to roll, just call:

CALL apoc.graph.fromDB('Movies', null) YIELD graph

That will pop the whole DB into your browser – now if you do this with a MONSTER database, you’ll only see the first 300 nodes – otherwise no matter your browser you could expect epic failures.

Typically we want to RETURN something rather than just put it on the screen so:

CALL apoc.graph.fromDB('A1Graphs', null) YIELD graph
RETURN *

Oh look – exactly the same – HANDY.

Let’s (for the sake of something) pretend that we have 2 of these and we’re wanting to check the name:

CALL apoc.graph.fromDB('A1Graphs', null) YIELD graph
RETURN graph.name

That’ll get us:

image

(and the award for the dullest blog post picture goes to..)

Let’s set and get some properties:

CALL apoc.graph.fromDB('A1Graphs', {Hello: 'World'}) YIELD graph
RETURN graph.properties

Which returns

image

But if we just want one property:

CALL apoc.graph.fromDB('A1Graphs', {Hello: 'World'}) YIELD graph
RETURN graph.properties.Hello

Note – I’ve used an upper case property name, so I have to use the same case when pulling them out – (I refuse to be cowed into Java conventions). Anyhews, that returns:

image

Notes

You always  need to YIELD unless you literally want to dump your DB to the screen – doing something like:

CALL apoc.graph.fromDB('A1Graphs', null) AS myGraph

Will lead to exceptions – as Neo4j is expecting you to YIELD, you can do:

CALL apoc.graph.fromDB('A1Graphs', null) YIELD graph AS myGraph

and use myGraph throughout the rest of your code no worries.