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]
<mailto:[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]> <mailto:[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]
<mailto:neo4j%[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.
