Support serialization/deserialization

[aseemk]

If I have a Node or Relationship instance and I want to cache it, currently there's no good way of serializing that instance to a string and deserializing that string back to an instance.

E.g. JSON.stringify() gets me a JSON string of an instance's full private data — we'll want to add toJSON() methods to our prototypes so we get the JSON we want — but JSON.parse() won't be able to take that string and give me back a proper class instance... unless we use a reviver function!

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/JSON/stringify

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/JSON/parse

It's worth looking into the options, but supporting these two things seems like a good start.

[aseemk]

/cc @davestern as FYI that we're tracking this now. =)

[sarpdoruk]

Don't know if implemented but I may implement those methods as an extension to the GraphDatabase or Util class, but I don't see any way of understanding if a JSON string is a node or a relationship (Correct me if I'm wrong). One way I can think of is before serializing the object we can add a property to it called "type" let's say and the value for the type would be object.constructor.name and that would be either "Node" or "Relationship". So this way, when we are parsing the JSON back from string, we can easily understand if it was a Node or a Relationship before. After parsing it back we can delete the unnecessary property "type" we have created before. Do you have any suggestions ?

[aseemk]

That sounds like a fine approach to me, @sarpdoruk. Good thinking!

Another approach could be to look at the node's/relationship's self URL, which has "node" or "relationship" in it. The PropertyContainer class does this:

https://github.com/thingdom/node-neo4j/blob/master/lib/PropertyContainer._coffee#L59

But I think your idea is cleaner.

And yep, this "parse" or "revive" method should be on the GraphDatabase class.

Thanks @sarpdoruk! Looking forward to your contribution if you choose to tackle this! =)

[sarpdoruk]

Thanks for the suggestion @aseemk.

I thought of the same idea, looking inside the self URL, but as you would agree I don't think it is neat approach.

I'll be digging into this issue (:

[aseemk]

I experienced a sudden onset of inspiration and motivation for this feature today while doing (i.e. waiting for) my laundry. =) Went ahead and implemented — try it out!

str = JSON.stringify [node, {foo: bar: relationship}]
obj = JSON.parse str, db.reviveJSON
# obj[0] and obj.foo.bar are again Node and Relationship instances

Not published to npm yet, but soon. Just waiting for a Streamline update to fix #76. =)

[sarpdoruk]

@aseemk I took a look at the code; you have decided to go with my suggestion. It seems a few lines of code is enough to implement such method :) Cool new feature btw.

[aseemk]

@sarpdoruk: Indeed! I just added some node-neo4j identification/versioning, and decided to call it constructor rather than type to both be more precise and to prevent conflicts with Relationship#type. =)

Okay! This has been published to npm as version 1.1.0!