Hi Ido, Those make good sense. And I think I have some reasonable RESTful approaches in mind for tackling them which don't need transactions (using Ian Robinson's typed links to forms approach here).
1. Bulk create of nodes and relations: - PUT a set of nodes and relations to the server, relative to some node, or to the graph itself. - Work needed: define a graph format (e.g. using JSON) to describe nodes and relations. 2. Remove relations: - GET a "removal form" (optional, will be cacheable for a long time anyway) - Populate the removal form with the nodes to be deleted, POST it to the server - Server responds with the URI of a (transient) resource that represents all the nodes and relations you previously specified. - DELETE the transient resource - Work needed: design a "removal form" (effectively a deletion manifest), a little processing logic on the server side 3. Clone subgraphs - Use a form to select a start node, terminating condition (e.g. depth), POST its URI to the cloning URI with a traversal description (or just something as simple as a termination condition for a df/bf search) which itself is created by filling in a form. - Work needed: a clone algorithm for the server; form that allows us to describe the graph for the clone; URI to POST back the form to the graph. OK, so there's some substantial work to be done here. But there's a positive point to take away from this. In the latest milestone release we have a Plugin mechanism where end users are able to extend the behaviour of graphs/nodes in order to implement all these kinds of domain specific things. Right now as we're testing the new Plugin stuff, I'm going to implement a simple clone subgraph plugin. I'll post the code and the wire-level HTTP here when I'm done so you can see how you might implement similar stuff for your domain (the code will also be in SVN under examples/server-extension). Jim PS - It occurs to me though, that if 3rd party plugins become very popular, we could over time bring them into core and take some responsibility for them. Perhaps. _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
