While I agree that JSON has very broad acceptance and use, I have to disagree on one very major point: JSON is a data interchange format, not a data type. The distinction is quite significant.
This thread was spawned from a previous closed conversation but my understanding is that you want to store arbitrarily nested maps as property values and that, up until now, you have been using JSON strings to hold these maps in serialised form. If that is the case, then the idea under discussion is perfectly appropriate for your use case and any map implementation would almost certainly use a Map<String, Object> internally to hold its data. This would then probably be converted to a JSON object over REST - although this would cause ambiguity with existing objects used for node and relationship representation. Regardless of the precise implementation though, I think we're all broadly talking about the same thing. Nige On 29 December 2013 07:09, Alan Robertson <[email protected]> wrote: > JSON is a well-recognized data type with clear semantics which is > well-supported by other NOSQL databases. It is the lingua franca of user > interfaces - with extremely broad acceptance and use. In this sense, it's > far more interesting than almost any other added type. The syntax and > semantics of handling it are clear and straightforward and documented as a > standard. > > Virtually everyone who writes a user interface will be dealing with JSON > at some level. > > They could implement maps of {map, bool, string, array, int, float, null) > and that would be a cleaner final implementation - provided the arrays can > be arrays with any given element being any one of the above types. > > > > > > On 12/28/2013 3:49 PM, Nigel Small wrote: > > Java can certainly handle Map<String, Object> which is the usual way to > represent a JSON-esque object. The example I gave was simply an easier one > to describe the idea as dates are built-in and JSON (de)serialisation > requires a third-party library. The same theory should hold to be able to > convert stringified *_json property values into Map<String, Object> values. > > In terms of what Cypher could/should do with converted data, I'm not > sure that Cypher would be the right place to do much manipulation anyway. > Such values should probably simply be passed back to the calling > application as opaque Objects and it would be up to that application to > use/inspect them. Anything else would require Cypher to be extended in > different directions for each new type supported. > > Nige > > > On 28 December 2013 17:01, Alan Robertson <[email protected]> wrote: > >> I don't understand how this would help my use case. I don't have any >> problem serializing/deserializing it. The example you gave seems too >> trivial to be helpful. >> >> Given that Java doesn't natively handle untyped/flexible data structures >> like JSON objects, and Neo4j certainly isn't prepared to handle them - this >> seems to be by far the more important part. >> >> The issue really is what Cypher can do with data. Or if you prefer, why >> they don't have (untyped) maps that would be JSON-compatible. >> >> Either way, the serialization/deserialization doesn't seem nearly >> sufficient to solve the problem. >> >> Maybe I missed something. Please enlighten me. >> >> >> >> On 12/28/2013 3:23 AM, Nigel Small wrote: >> >> I very much like Craig/Axel's idea of being able to tag certain property >> keys such that their related values go through a (de)serialisation handler >> on read/write. The implementation could use the plugin mechanism to >> register converters that implement custom read/write routines, something >> like: >> >> public class StringToDateConverter implements PropertyConverter<String, >> Date> { >> >> private SimpleDateFormat formatter = new >> SimpleDateFormat("yyyy-MM-dd"); >> >> public Date read(String value) { >> return formatter.parse(value); >> } >> >> public String write(Date value) { >> return formatter.format(value); >> } >> >> } >> >> Then these could be registered in Cypher, much like indexes, to match >> property keys that are named in a particular way... >> >> CREATE HANDLER FOR '.*_date' USING 'StringToDateConverter' >> >> There would certainly be some challenges to overcome though, not least >> with exception handling and REST serialisation, but I daresay these aren't >> insurmountable. >> >> Nige >> >> >> >> On 28 December 2013 05:10, Alan Robertson <[email protected]> wrote: >> >>> On 12/07/2013 02:58 AM, Michael Hunger wrote: >>> >>> Let's move this whole discussion to the google group :) >>> >>> Map support for properties is planned and almost made it into the >>> product some time ago but then were some considerations so that it sadly >>> didn't work out. >>> >>> User defined functions would be a way to go but much better with real >>> support by the storage engine and language. >>> >>> Wes, didn't you want to look into a UDF PoC? >>> >>> >>> Here is a very specific and real use case for such a user defined >>> function (or map capability) for JSON: >>> >>> I have a discovery item in JSON which collects ulimit values and looks >>> like this: >>> { >>> "discovertype": "ulimit", >>> "description": "ulimit values for root", >>> "host": "servidor", >>> "source": "/usr/share/assimilation/discovery_agents/ulimit", >>> "data": { >>> "hard": {"c":null,"d":null,"f":null,"l":64,"m":null,*"n":1024* >>> ,"p":47013,"s":null,"t":null,"v":null}, >>> "soft": {"c":0,"d":null,"f":null,"l":64,"m":null,*"n":1024* >>> ,"p":47013,"s":8192,"t":null,"v":null} >>> } >>> } >>> >>> >>> This is the results of the ulimit discovery module. I used the JSON >>> value null to represent the ulimit value unlimited. >>> >>> One of those flags (-*n*) is the maximum number of open files. As you >>> can see, this example is out of compliance with Neo4j best practices ;-). >>> >>> This is in a field called JSON_ulimit. >>> >>> So, if I wanted to see if a machine had enough open files to follow >>> neo4j best practices, I would like to check *JSON_ulimit.data.soft.n*and >>> see if it was greater or equal to 50000 (or null) on every machine >>> running neo4j. >>> >>> As it is now, I can't do this in Cypher. I have to do it in python (or >>> Java, or...) >>> >>> I'd love to have a way to do this in Cypher. >>> >>> *Michael: *Could I represent this data and perform this query with the >>> proposed map capability? >>> *Wes:* Could you make such a query work with a user-defined function? >>> >>> Don't you want me to be able to tell your customers they're not in >>> compliance with Neo4j best practices? :-D >>> >>> >>> >>> -- >>> Alan Robertson <[email protected]> <[email protected]> - @OSSAlanR >>> >>> "Openness is the foundation and preservative of friendship... Let me claim >>> from you at all times your undisguised opinions." - William Wilberforce >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
