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.
