JSON string export - are we asking for trouble?

[mtholder]

We seem to just be composing JSON by hand, which is typically easy. We could use something like: http://jettison.codehaus.org/apidocs/org/codehaus/jettison/json/JSONStringer.html

In many cases we know that the strings are safe for JSON (in which case it is probably faster to not check to see if we need to escape them). I may be the most guilty party here, as I just worked on spitting out metadata for studies. We could easily have quotes or unicode in those strings associated with references. In which case my code would generate bogus JSON.

That data came from phylografter via JSON, so I'm hoping that it is clean.

Deciding that the db will hold strings that are already escaped for JSON would make life easier. Have we decided that? (if so are we checking this on ingesting of trees?).

[rhr]

I am pretty sure all JSON from phylografter is generated by gluon.serializers.json, which means it's escaped and utf8-encoded.

On Tue, Apr 30, 2013 at 10:34 PM, Mark Holder notifications@github.comwrote:

We seem to just be composing JSON by hand, which is typically easy. We could use something like: http://jettison.codehaus.org/apidocs/org/codehaus/jettison/json/JSONStringer.html

In many cases we know that the strings are safe for JSON (in which case it is probably faster to not check to see if we need to escape them). I may be the most guilty party here, as I just worked on spitting out metadata for studies. We could easily have quotes or unicode in those strings associated with references. In which case my code would generate bogus JSON.

That data came from phylografter via JSON, so I'm hoping that it is clean.

Deciding that the db will hold strings that are already escaped for JSON would make life easier. Have we decided that? (if so are we checking this on ingesting of trees?).

— Reply to this email directly or view it on GitHubhttps://github.com/OpenTreeOfLife/treemachine/issues/27 .

[chinchliff]

Another option is to extend the neo4j serializers, as is done with the TNRS. Not sure if there is an advantage or disadvantage to this relative to other methods.

On Tuesday, April 30, 2013, Rick Ree wrote:

I am pretty sure all JSON from phylografter is generated by gluon.serializers.json, which means it's escaped and utf8-encoded.

On Tue, Apr 30, 2013 at 10:34 PM, Mark Holder <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>>wrote:

We seem to just be composing JSON by hand, which is typically easy. We could use something like:

http://jettison.codehaus.org/apidocs/org/codehaus/jettison/json/JSONStringer.html

In many cases we know that the strings are safe for JSON (in which case it is probably faster to not check to see if we need to escape them). I may be the most guilty party here, as I just worked on spitting out metadata for studies. We could easily have quotes or unicode in those strings associated with references. In which case my code would generate bogus JSON.

That data came from phylografter via JSON, so I'm hoping that it is clean.

Deciding that the db will hold strings that are already escaped for JSON would make life easier. Have we decided that? (if so are we checking this on ingesting of trees?).

— Reply to this email directly or view it on GitHub< https://github.com/OpenTreeOfLife/treemachine/issues/27> .

— Reply to this email directly or view it on GitHubhttps://github.com/OpenTreeOfLife/treemachine/issues/27#issuecomment-17267413 .

[chinchliff]

Closing this issue, refer to issue #32.