The idea of letting users control transactions is controversial. Transactions are usually an implementation detail of systems, that clients shouldn't be aware of. However as a database, we might be more lenient in this case.
But in terms of your proposed message exchanges, there are some problems because you're tunnelling actions through URIs and ignoring the HTTP method.
That can't be. GET is idempotent. Creating a transaction will have to be a post to some resource and then either a direct response or a redirect followed by GET.
we're happy to find out about this ongoing effort of a transaction aware REST server.
Some questions:
* Is the intention of fast-http to replace the current neo4j-rest-server? * Is there any roadmap / time frame about a stable release? * Is it already usable? * Is there some installation documentation?
Sent from my phone, please excuse typos and brievety.
On May 4, 2012 3:33 PM, "Nicolas Dietrich" <nicodietr...@gmail.com> wrote:
> Hi Michael & Jacob,
> we're happy to find out about this ongoing effort of a transaction aware
REST server.
> Some questions:
> * Is the intention of fast-http to replace the current neo4j-rest-server?
No. Fast-HTTP is a prototype we built to get an idea of how much
performance we can get out of HTTP, as well as sketching on extensions to
the current REST API.
> * Is there any roadmap / time frame about a stable release?
No, fast-http is not part of our planned pipeline.
> * Is it already usable?
Kind of, basic support for node / relationship CRUD and transactions are
supported.
> * Is there some installation documentation?
No, it can be started as a java app from within eclipse, see the
Neo4jServer class. See the integration tests for API syntax.
> Thanks and cheers,
> Nicolas
> On Thursday, March 29, 2012 9:47:01 AM UTC+2, Michael Hunger wrote:
>> This is addressed in a new implementation of the http-endpoints (which
Hi, I'm planning on building a business webservice on top of a graph db , and i'm currently in the process of designing my data layer on top of neo4j. For now, i'm using py2neo (a python lib i found which uses REST Api) and would badly need some way of performing transaction. I've had a look at the github project you mentionned, but it doesn't seem to have been updated for the last 6 months.
On Saturday, May 5, 2012 1:23:13 PM UTC+2, Jacob Hansson wrote:
> Sent from my phone, please excuse typos and brievety. > On May 4, 2012 3:33 PM, "Nicolas Dietrich" <nicodi...@gmail.com<javascript:>> > wrote:
> > Hi Michael & Jacob,
> > we're happy to find out about this ongoing effort of a transaction aware > REST server.
> > Some questions:
> > * Is the intention of fast-http to replace the current > neo4j-rest-server?
> No. Fast-HTTP is a prototype we built to get an idea of how much > performance we can get out of HTTP, as well as sketching on extensions to > the current REST API.
> > * Is there any roadmap / time frame about a stable release?
> No, fast-http is not part of our planned pipeline.
> > * Is it already usable?
> Kind of, basic support for node / relationship CRUD and transactions are > supported.
> > * Is there some installation documentation?
> No, it can be started as a java app from within eclipse, see the > Neo4jServer class. See the integration tests for API syntax.
> > Thanks and cheers, > > Nicolas
> > On Thursday, March 29, 2012 9:47:01 AM UTC+2, Michael Hunger wrote:
> >> This is addressed in a new implementation of the http-endpoints (which > is still work in progress).
benjamin.garrig...@gmail.com> wrote:
> Hi,
> I'm planning on building a business webservice on top of a graph db , and
> i'm currently in the process of designing my data layer on top of neo4j.
> For now, i'm using py2neo (a python lib i found which uses REST Api) and
> would badly need some way of performing transaction. I've had a look at the
> github project you mentionned, but it doesn't seem to have been updated for
> the last 6 months.
> Do you have any recommendation ?
> Thanks,
> Benjamin
> On Saturday, May 5, 2012 1:23:13 PM UTC+2, Jacob Hansson wrote:
>> Sent from my phone, please excuse typos and brievety.
>> On May 4, 2012 3:33 PM, "Nicolas Dietrich" <nicodi...@gmail.com> wrote:
>> > Hi Michael & Jacob,
>> > we're happy to find out about this ongoing effort of a transaction
>> aware REST server.
>> > Some questions:
>> > * Is the intention of fast-http to replace the current
>> neo4j-rest-server?
>> No. Fast-HTTP is a prototype we built to get an idea of how much
>> performance we can get out of HTTP, as well as sketching on extensions to
>> the current REST API.
>> > * Is there any roadmap / time frame about a stable release?
>> No, fast-http is not part of our planned pipeline.
>> > * Is it already usable?
>> Kind of, basic support for node / relationship CRUD and transactions are
>> supported.
>> > * Is there some installation documentation?
>> No, it can be started as a java app from within eclipse, see the
>> Neo4jServer class. See the integration tests for API syntax.
>> > Thanks and cheers,
>> > Nicolas
>> > On Thursday, March 29, 2012 9:47:01 AM UTC+2, Michael Hunger wrote:
>> >> This is addressed in a new implementation of the http-endpoints (which
>> is still work in progress).
> On Mon, Nov 5, 2012 at 4:44 AM, Benjamin Garrigues <
> benjamin.garrig...@gmail.com> wrote:
>> Hi,
>> I'm planning on building a business webservice on top of a graph db , and
>> i'm currently in the process of designing my data layer on top of neo4j.
>> For now, i'm using py2neo (a python lib i found which uses REST Api) and
>> would badly need some way of performing transaction. I've had a look at the
>> github project you mentionned, but it doesn't seem to have been updated for
>> the last 6 months.
>> Do you have any recommendation ?
>> Thanks,
>> Benjamin
>> On Saturday, May 5, 2012 1:23:13 PM UTC+2, Jacob Hansson wrote:
>>> Sent from my phone, please excuse typos and brievety.
>>> On May 4, 2012 3:33 PM, "Nicolas Dietrich" <nicodi...@gmail.com> wrote:
>>> > Hi Michael & Jacob,
>>> > we're happy to find out about this ongoing effort of a transaction
>>> aware REST server.
>>> > Some questions:
>>> > * Is the intention of fast-http to replace the current
>>> neo4j-rest-server?
>>> No. Fast-HTTP is a prototype we built to get an idea of how much
>>> performance we can get out of HTTP, as well as sketching on extensions to
>>> the current REST API.
>>> > * Is there any roadmap / time frame about a stable release?
>>> No, fast-http is not part of our planned pipeline.
>>> > * Is it already usable?
>>> Kind of, basic support for node / relationship CRUD and transactions are
>>> supported.
>>> > * Is there some installation documentation?
>>> No, it can be started as a java app from within eclipse, see the
>>> Neo4jServer class. See the integration tests for API syntax.
>>> > Thanks and cheers,
>>> > Nicolas
>>> > On Thursday, March 29, 2012 9:47:01 AM UTC+2, Michael Hunger wrote:
>>> >> This is addressed in a new implementation of the http-endpoints
>>> (which is still work in progress).
Hi, thanks you both for your answers. I've since found the bulb library and
i'm waiting for more info on that library before making my mind as to the
architecture of my data layer.
I started with model get and post and found py2neo + cypher quite powerful,
but now that i'm thinking about updates, i feel like I could use the help
of a more active-record like framework for managing state sync between my
model and the graph db (I even started some crazy automatic persistence of
native python objects on a graph using introspection, automatically mapping
property names to relationships, which kind of work as long as you don't
need to diff :)).
>> On Mon, Nov 5, 2012 at 4:44 AM, Benjamin Garrigues <
>> benjamin.garrig...@gmail.com> wrote:
>>> Hi,
>>> I'm planning on building a business webservice on top of a graph db ,
>>> and i'm currently in the process of designing my data layer on top of neo4j.
>>> For now, i'm using py2neo (a python lib i found which uses REST Api) and
>>> would badly need some way of performing transaction. I've had a look at the
>>> github project you mentionned, but it doesn't seem to have been updated for
>>> the last 6 months.
>>> Do you have any recommendation ?
>>> Thanks,
>>> Benjamin
>>> On Saturday, May 5, 2012 1:23:13 PM UTC+2, Jacob Hansson wrote:
>>>> Sent from my phone, please excuse typos and brievety.
>>>> On May 4, 2012 3:33 PM, "Nicolas Dietrich" <nicodi...@gmail.com> wrote:
>>>> > Hi Michael & Jacob,
>>>> > we're happy to find out about this ongoing effort of a transaction
>>>> aware REST server.
>>>> > Some questions:
>>>> > * Is the intention of fast-http to replace the current
>>>> neo4j-rest-server?
>>>> No. Fast-HTTP is a prototype we built to get an idea of how much
>>>> performance we can get out of HTTP, as well as sketching on extensions to
>>>> the current REST API.
>>>> > * Is there any roadmap / time frame about a stable release?
>>>> No, fast-http is not part of our planned pipeline.
>>>> > * Is it already usable?
>>>> Kind of, basic support for node / relationship CRUD and transactions
>>>> are supported.
>>>> > * Is there some installation documentation?
>>>> No, it can be started as a java app from within eclipse, see the
>>>> Neo4jServer class. See the integration tests for API syntax.
>>>> > Thanks and cheers,
>>>> > Nicolas
>>>> > On Thursday, March 29, 2012 9:47:01 AM UTC+2, Michael Hunger wrote:
>>>> >> This is addressed in a new implementation of the http-endpoints
>>>> (which is still work in progress).
> Hi, thanks you both for your answers. I've since found the bulb library
> and i'm waiting for more info on that library before making my mind as to
> the architecture of my data layer.
> I started with model get and post and found py2neo + cypher quite
> powerful, but now that i'm thinking about updates, i feel like I could use
> the help of a more active-record like framework for managing state sync
> between my model and the graph db (I even started some crazy automatic
> persistence of native python objects on a graph using introspection,
> automatically mapping property names to relationships, which kind of work
> as long as you don't need to diff :)).
> On Mon, Nov 5, 2012 at 3:56 PM, Nigel Small <ni...@nigelsmall.net> wrote:
>> Hi Benjamin
>> I have just replied to what I assume is your post on SO:
>>> On Mon, Nov 5, 2012 at 4:44 AM, Benjamin Garrigues <
>>> benjamin.garrig...@gmail.com> wrote:
>>>> Hi,
>>>> I'm planning on building a business webservice on top of a graph db ,
>>>> and i'm currently in the process of designing my data layer on top of neo4j.
>>>> For now, i'm using py2neo (a python lib i found which uses REST Api)
>>>> and would badly need some way of performing transaction. I've had a look at
>>>> the github project you mentionned, but it doesn't seem to have been updated
>>>> for the last 6 months.
>>>> Do you have any recommendation ?
>>>> Thanks,
>>>> Benjamin
>>>> On Saturday, May 5, 2012 1:23:13 PM UTC+2, Jacob Hansson wrote:
>>>>> Sent from my phone, please excuse typos and brievety.
>>>>> On May 4, 2012 3:33 PM, "Nicolas Dietrich" <nicodi...@gmail.com>
>>>>> wrote:
>>>>> > Hi Michael & Jacob,
>>>>> > we're happy to find out about this ongoing effort of a transaction
>>>>> aware REST server.
>>>>> > Some questions:
>>>>> > * Is the intention of fast-http to replace the current
>>>>> neo4j-rest-server?
>>>>> No. Fast-HTTP is a prototype we built to get an idea of how much
>>>>> performance we can get out of HTTP, as well as sketching on extensions to
>>>>> the current REST API.
>>>>> > * Is there any roadmap / time frame about a stable release?
>>>>> No, fast-http is not part of our planned pipeline.
>>>>> > * Is it already usable?
>>>>> Kind of, basic support for node / relationship CRUD and transactions
>>>>> are supported.
>>>>> > * Is there some installation documentation?
>>>>> No, it can be started as a java app from within eclipse, see the
>>>>> Neo4jServer class. See the integration tests for API syntax.
>>>>> > Thanks and cheers,
>>>>> > Nicolas
>>>>> > On Thursday, March 29, 2012 9:47:01 AM UTC+2, Michael Hunger wrote:
>>>>> >> This is addressed in a new implementation of the http-endpoints
>>>>> (which is still work in progress).
