Re: [Neo4j] Transaction and REST API

[Peter Neubauer]

Yes,
+ 1 on contributions of useful rest plugins. I would like to see them listed
in the manual, and keep the docs somewhere central. Suggestions?
On Oct 27, 2011 12:35 PM, "Kristen Eisenberg" 
wrote:

> Hi Ido,
>
> > How will you go about implement such change using REST interface?
>
> With the current default REST interface, you can't. But you can write an
> extension (either in the managed framework, or if you're brave/desperate in
> the unmanaged framework through JAX-RS) which can do this.
>
> I imagine you might give such a resource the name:
>
> .../products
>
> When you POST a new product representation to the /products resource, under
> the covers it creates both a new node that represents your product and
> inserts the relationship into the DB too.
>
> > Another example in the same area is suppose I want to change 2 links, say
> > change a category from been sub-category to another sub-category and
> let's
> > say it involve delete one link and create another.
>
> Same deal, although the discovery is a little trickier here. If you were to
> do this in a sane way, I'd suggest filling in a form, which contains the URI
> of the relationship to be deleted, plus the information needed to create a
> new relationship. POST that form to a resource representing the graph and
> you're done.
>
> > I'm trying to see if there is a generic way to implement such things of
> > changing multiple resources in generic manager in REST or is it simply to
> > application (or service) specific.
>
> I think they're mostly going to be application specific. That's why we have
> the two ways of extending the server (warning: the JAX-RS way really is a
> sharp tool, be careful). But if the community notices useful patterns
> emerging, then we could think about rolling them up into a general
> extensions package (rather like the very useful graph algos package).
>
> So a plea to the community: if you extend the server in any cool and useful
> way, let the group know and we'll perhaps get a rest-contrib project
> running.
>
> Happy new year everybody!
>
>
> Kristen Eisenberg
> Billige Flüge
> Marketing GmbH
> Emanuelstr. 3,
> 10317 Berlin
> Deutschland
> Telefon: +49 (33)
> 5310967
> Email:
> utebachmeier at
> gmail.com
> Site:
> http://flug.airego.de
> - Billige Flüge vergleichen
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] Transaction and REST API

[Kristen Eisenberg]

Hi Ido,

> How will you go about implement such change using REST interface?

With the current default REST interface, you can't. But you can write an 
extension (either in the managed framework, or if you're brave/desperate in the 
unmanaged framework through JAX-RS) which can do this. 

I imagine you might give such a resource the name:

.../products

When you POST a new product representation to the /products resource, under the 
covers it creates both a new node that represents your product and inserts the 
relationship into the DB too.

> Another example in the same area is suppose I want to change 2 links, say
> change a category from been sub-category to another sub-category and let's
> say it involve delete one link and create another.

Same deal, although the discovery is a little trickier here. If you were to do 
this in a sane way, I'd suggest filling in a form, which contains the URI of 
the relationship to be deleted, plus the information needed to create a new 
relationship. POST that form to a resource representing the graph and you're 
done.

> I'm trying to see if there is a generic way to implement such things of
> changing multiple resources in generic manager in REST or is it simply to
> application (or service) specific.

I think they're mostly going to be application specific. That's why we have the 
two ways of extending the server (warning: the JAX-RS way really is a sharp 
tool, be careful). But if the community notices useful patterns emerging, then 
we could think about rolling them up into a general extensions package (rather 
like the very useful graph algos package).

So a plea to the community: if you extend the server in any cool and useful 
way, let the group know and we'll perhaps get a rest-contrib project running.

Happy new year everybody!


Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de
- Billige Flüge vergleichen
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Jim Webber]

Hi Ido,

> How will you go about implement such change using REST interface?

With the current default REST interface, you can't. But you can write an 
extension (either in the managed framework, or if you're brave/desperate in the 
unmanaged framework through JAX-RS) which can do this. 

I imagine you might give such a resource the name:

.../products

When you POST a new product representation to the /products resource, under the 
covers it creates both a new node that represents your product and inserts the 
relationship into the DB too.

> Another example in the same area is suppose I want to change 2 links, say
> change a category from been sub-category to another sub-category and let's
> say it involve delete one link and create another.

Same deal, although the discovery is a little trickier here. If you were to do 
this in a sane way, I'd suggest filling in a form, which contains the URI of 
the relationship to be deleted, plus the information needed to create a new 
relationship. POST that form to a resource representing the graph and you're 
done.

> I'm trying to see if there is a generic way to implement such things of
> changing multiple resources in generic manager in REST or is it simply to
> application (or service) specific.

I think they're mostly going to be application specific. That's why we have the 
two ways of extending the server (warning: the JAX-RS way really is a sharp 
tool, be careful). But if the community notices useful patterns emerging, then 
we could think about rolling them up into a general extensions package (rather 
like the very useful graph algos package).

So a plea to the community: if you extend the server in any cool and useful 
way, let the group know and we'll perhaps get a rest-contrib project running.

Happy new year everybody!

Jim
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Ido Ran]

OK, I think I understand what you are saying.
Let's try to do an example in the field of graph (after all that's why were
here :)

neo4j is generic graph database. One of the interesting usage of graph is to
give meaning to a node by the relations it has, like the category and
product 
sample
.
In that case when I want to add new product I need to do 2 things:

   1. Create new node with the name of the product
   2. Create new link of type PRODUCT from the category to the new node

How will you go about implement such change using REST interface?

Another example in the same area is suppose I want to change 2 links, say
change a category from been sub-category to another sub-category and let's
say it involve delete one link and create another.

I'm trying to see if there is a generic way to implement such things of
changing multiple resources in generic manager in REST or is it simply to
application (or service) specific.

Thank you,
Ido

On Thu, Dec 30, 2010 at 6:14 PM, Jim Webber  wrote:

> Hi Ido,
>
> [off topic for folks who are just interested in graphs, here be REST
> things]
>
> > My question is Should I have a generic Transaction resource to allow
> atomic
> > changes to any resource in my service which represent data?
>
> No, I don't think so (unless you mean a transaction in the commercial
> sense).
>
> Instead I still think I should be able to interact with a "Transfer"
> resource which under the covers might (or might not) need some kind of
> coordination (similar to 2pc).
>
> If you want to go with that then I suggest both services simple broadcast
> the activities they considered completed (e.g. using an atom feed of
> events). This is a superior solution to that initially suggested by the
> (flawed IMHO) REST-* people.
>
> However I really think that hypermedia wins out here. Instead of a
> distributed 2 phase transaction, why not do this instead:
>
> 1. Client knows the source and destination account URIs
> 2. Client PUTs a transfer representation to a transfer resource related to
> the source account, that representation contains the URI of the destination
> account resource
> 3. The source account service now does a "single-phase" PUT to the
> destination resource.
>
> Any transactions are now under the covers, bounded by a single, repeatable,
> idempotent PUT.
>
> Sweet.
>
> Jim
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Jim Webber]

Hi Ido,

[off topic for folks who are just interested in graphs, here be REST things]

> My question is Should I have a generic Transaction resource to allow atomic
> changes to any resource in my service which represent data?

No, I don't think so (unless you mean a transaction in the commercial sense).

Instead I still think I should be able to interact with a "Transfer" resource 
which under the covers might (or might not) need some kind of coordination 
(similar to 2pc). 

If you want to go with that then I suggest both services simple broadcast the 
activities they considered completed (e.g. using an atom feed of events). This 
is a superior solution to that initially suggested by the (flawed IMHO) REST-* 
people.

However I really think that hypermedia wins out here. Instead of a distributed 
2 phase transaction, why not do this instead:

1. Client knows the source and destination account URIs
2. Client PUTs a transfer representation to a transfer resource related to the 
source account, that representation contains the URI of the destination account 
resource
3. The source account service now does a "single-phase" PUT to the destination 
resource.

Any transactions are now under the covers, bounded by a single, repeatable, 
idempotent PUT.

Sweet.

Jim
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Ido Ran]

The way I see it in REST architecture Resource is anything of interest which
in simple words can be either data or functionality.

After we create ListResource and IndividualResource for each data item we
have in our business domain (which already put 2:1 ratio between resources
and domain model) it is time to add the functionality resource.
In bank application there might be a resource for transferring money between
accounts. There is no TransferMoneyData (although there usually a log entry
for that) but it is an interesting functionality of the service.

My question is Should I have a generic Transaction resource to allow atomic
changes to any resource in my service which represent data?

Thank you,
Ido

On Thu, Dec 23, 2010 at 11:47 AM, Jim Webber  wrote:

> Hi Ido,
>
>
> > BULK resource are not so likable on RESTful people, but I guess it can
> work
> > really well for my case.
>
> I think you're both right and wrong here :-)
>
> You're wrong when you say RESTful people don't like bulk updates. We do,
> but we prefer those updates to be just the same as any other update - that
> is a PUT (usually) to a resource that represents many individual entities in
> the DB.
>
> People who don't understand REST will complain that there is no atomicity
> when the have to PUT updates to individual resources where there is a 1:1
> mapping between resources and the domain model. In general, O(resources) >>
> O(domain entities) in a RESTful system.
>
> You're right when you say it's a good fit for your use case - because it's
> the right thing to do.
>
> Merry Christmas,
>
> Jim
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Jim Webber]

Hi Ido,


> BULK resource are not so likable on RESTful people, but I guess it can work
> really well for my case.

I think you're both right and wrong here :-)

You're wrong when you say RESTful people don't like bulk updates. We do, but we 
prefer those updates to be just the same as any other update - that is a PUT 
(usually) to a resource that represents many individual entities in the DB.

People who don't understand REST will complain that there is no atomicity when 
the have to PUT updates to individual resources where there is a 1:1 mapping 
between resources and the domain model. In general, O(resources) >> O(domain 
entities) in a RESTful system.

You're right when you say it's a good fit for your use case - because it's the 
right thing to do.

Merry Christmas,

Jim

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Ido Ran]

Well, as you said there are number of ways to do it.
This post describe a way to do
it,
but it's not the post that is the main issue but the comments below it.
There is still no consensus about what is the RESTful way of doing tx in
RESTful web service.

For sure POST a tx start url and POST for commit (while holding a real
database tx) is not a good solution for me. It's not scalable and will block
users from even READ depend on my isolation level in the database.

I guess it all comes down to how specific my RESTful interface. In my
example the current need for tx is to create or delete both node and link,
then I might as well create a resource that handle it and work with it.
The problem off course is that later on (sooner then I think) I will need to
create two links in one tx, and then I will need a new resource for two
links and so on.

BULK resource are not so likable on RESTful people, but I guess it can work
really well for my case.
I'll create a BULK change resource, fill it with the changes I want to do
and finally change it state to commit which will then and only then start a
DB tx, do the changes (maybe check ETag to make sure nothing change in
between) and finally commit the tx.

That's what I'm thinking about it.

Ido

On Mon, Dec 20, 2010 at 9:42 PM, Christopher Schmidt <
fakod...@googlemail.com> wrote:

> I written a couple of REST services and clients over the past years and it
> is always a subject of discussions: How to map transactions with a
> stateless
> RESTful service?
>
> We always did it like Neo4j, every REST call is a implicit transaction. If
> this is not sufficient we implemented BULK or combined calls for bulk
> deletions or creations etc. But the question is: Is it really impossible to
> implement transactions?
>
> We can use
> - the session context with invalidating a session or timeout is a rollback
> (this will be expensive...)
> - or POSTing a new transaction returning a Trx ID, subsequent write or
> update operations are containing a transaction ID
> - using custom HTTP header
> - (whatever)
>
> All this violates the stateless paradigm. But the reality of the Web is: we
> do have HTTP sessions, cookies, baskets etc. And scalability is a question
> of server implementation, isn't it?
>
> What do you think?
>
> On Mon, Dec 20, 2010 at 12:28 PM, Jim Webber 
> wrote:
>
> > 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
> >
>
>
>
> --
> Christopher
> twitter: @fakod
> blog: http://blog.fakod.eu
> ___
> Neo4j mailing list

Re: [Neo4j] Transaction and REST API

[Christopher Schmidt]

I written a couple of REST services and clients over the past years and it
is always a subject of discussions: How to map transactions with a stateless
RESTful service?

We always did it like Neo4j, every REST call is a implicit transaction. If
this is not sufficient we implemented BULK or combined calls for bulk
deletions or creations etc. But the question is: Is it really impossible to
implement transactions?

We can use
- the session context with invalidating a session or timeout is a rollback
(this will be expensive...)
- or POSTing a new transaction returning a Trx ID, subsequent write or
update operations are containing a transaction ID
- using custom HTTP header
- (whatever)

All this violates the stateless paradigm. But the reality of the Web is: we
do have HTTP sessions, cookies, baskets etc. And scalability is a question
of server implementation, isn't it?

What do you think?

On Mon, Dec 20, 2010 at 12:28 PM, Jim Webber  wrote:

> 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
>



-- 
Christopher
twitter: @fakod
blog: http://blog.fakod.eu
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Ido Ran]

Hi,
Thank you for the detailed answer.
The core of the answer is we should use resources to manage tx and not try
to mimik tx of begin, work, end like we used to do. If this is so I agree.

I'll keep track your changes and hopefully we'll find a way.

Ido

On Mon, Dec 20, 2010 at 1:28 PM, Jim Webber  wrote:

> 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
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Jim Webber]

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

Re: [Neo4j] Transaction and REST API

[Ido Ran]

OK, here are some of the use-cases:


   1. In my model the type of a node is derived from the relations it has like
   in this 
post.
   So the first thing is to make sure we create both the node and its
   relation(s).
   2. The same goes the other way around, when delete a sub-category in the
   example we want to remove both the link and the node in single tx.
   3. There are application specific use-case, for example in our
   application we have "process network" that is a network represent a single
   process and we want to clone that network which means create an exact
   replica but with a different name. If I need to create the nodes and links
   using repeated calls to the RESTful API and for any reason I lose connection
   in the middle I end up with partially cloned network.

I guess there are other use-cases but let's start with these.

Ido.


On Mon, Dec 20, 2010 at 10:10 AM, Jim Webber  wrote:

> Hi Ido,
>
> At the moment each interaction with the RESTful service causes a back-end
> transaction to occur. We have been hesitant to allow transactions outside of
> the service boundary because they're an implementation detail, rather than
> being part of the service contract.
>
> Could you tell us which use cases you're interested in? It may be that
> extending the REST interface is feasible, rather than exposing transaction
> demarcation facilities.
>
> JIm
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Transaction and REST API

[Jim Webber]

Hi Ido,

At the moment each interaction with the RESTful service causes a back-end 
transaction to occur. We have been hesitant to allow transactions outside of 
the service boundary because they're an implementation detail, rather than 
being part of the service contract.

Could you tell us which use cases you're interested in? It may be that 
extending the REST interface is feasible, rather than exposing transaction 
demarcation facilities.

JIm
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] Transaction and REST API

[Ido Ran]

Hello,
We are working on application which has graph as the main data model, not
social graph.
I am currently use J2EE 6 RESTful service and RDBMS as backend but I know if
has many weaknesses in term of graph processing and query.
I am interesting to see if I can replace my server side J2EE application
with nero4J server, without rewrite the whole client application.

I mostly interested in how do you expose RESTful interface and yet keep the
transaction working.
As far as I can see it either single changes without transaction, or
specific RESTful interface for executing transaction.
I've not seen any transaction related resource in your REST interface so is
it possible you do not support tx on the REST interface?

Thank you very much,
Ido.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user