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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/groups/opt_out.
