Re: [Neo4j] 1.5.M02 - JVM BootStrapper Issues

2011-11-05 Thread Romiko Derbynew
Indeed, they all JVM switches.

Sent from my iPhone

On 05/11/2011, at 5:34 PM, "Peter Neubauer"  
wrote:

> Romiko,
> this is probably linked to the same issue,
> https://github.com/neo4j/packaging/issues/2
> 
> Cheers,
> 
> /peter neubauer
> 
> GTalk:  neubauer.peter
> Skype   peter.neubauer
> Phone   +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter  http://twitter.com/peterneubauer
> 
> http://www.neo4j.org  - NOSQL for the Enterprise.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> 
> 
> 
> On Thu, Nov 3, 2011 at 4:07 PM, Romiko Derbynew
>  wrote:
>> Hi Guys,
>> 
>> I have downloaded the latest Community edition and notice these three custom 
>> lines of code causing the Neo4J server not to start up:
>> 
>> wrapper.java.additional.1=-d64
>> wrapper.java.additional.1=-server
>> wrapper.java.additional.1=-Xss2048k
>> 
>> With the previous version, they worked fine. They live at the bottom of the 
>> neo4j-wrapper.conf
>> 
>> Error I get is.
>> java.lang.IllegalArgumentException
>>at java.lang.ProcessImpl.(Unknown Source)
>>at java.lang.ProcessImpl.start(Unknown Source)
>>at java.lang.ProcessBuilder.start(Unknown Source)
>>at java.lang.Runtime.exec(Unknown Source)
>>at 
>> org.neo4j.wrapper.ServerProcessConsole.doStart(ServerProcessConsole.j
>> ava:39)
>>at org.neo4j.wrapper.ServerProcess.(ServerProcess.java:116)
>>at 
>> org.neo4j.wrapper.ServerProcessConsole.(ServerProcessConsole.ja
>> va:29)
>>at 
>> org.neo4j.wrapper.NeoServiceWrapper.launchAsConsoleApp(NeoServiceWrap
>> per.java:48)
>>at org.neo4j.wrapper.NeoServiceWrapper.main(NeoServiceWrapper.java:35)
>> 
>> Is this expected, since I am sure the JVM should support adding these 
>> additional parameters?
>> 
>> I want these in here, so I can always ensure it is 64bit, server mode with a 
>> stack size of 2048k
>> 
>> 
>> ___
>> 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 mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] Cypher->Pickle?

2011-11-05 Thread Javier de la Rosa
IMHO, the differential key of Cypher regarding to SQL, is the way in
which Cypher builds the "joins". I mean, the clause PATTERN or WHERE
written like "lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor" is pretty
powerful. The rest of the details are unimportant, in the sense they
already have an equivalence in SQL. So, I think to use SQL-like
queries could attract more people interested in Neo4j. And at the same
time, this people will discover the versatility of the Cypher JOINs.

Regards.

On Sat, Nov 5, 2011 at 10:33, Nigel Small  wrote:
>> newbies may find it helpful to start with something they already know.
> One problem with this is that it could invoke a tendency to try to map
> relational concepts onto a graph db. The two types of database are
> fundamentally different at the lowest level and if one starts off by
> thinking "where do I put my 'tables'?" they are only heading down the wrong
> path. I mentioned a while back that I felt designing a graph database is
> more akin to OO design that to relational design. Maybe we should stop
> using the word "database"?? :-P
> *
> *
> *Nigel Small*
> Phone: +44 7814 638 246
> Blog: http://nigelsmall.name/
> GTalk: ni...@nigelsmall.name
> MSN: nasm...@live.co.uk
> Skype: technige
> Twitter: @technige 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>
>
>
> On 5 November 2011 14:03, Axel Morgner  wrote:
>
>> People already familiar with graphs seem to love the original Cypher
>> syntax while newbies may find it helpful to start with something they
>> already know.
>>
>> What about letting both coexist peacefully?
>>
>> Axel
>>
>>
>> Am 05.11.2011 14:29, schrieb Andres Taylor:
>> > On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
>> >> I really don't want Cypher to pander to SQL. Cypher is about graph
>> > matching and should be awesome at it
>> >
>> > PQL isn't any different in this aspect. Mattias' ascii-art is still the
>> way
>> > to describe your pattern. Cypher is already very like SQL in many ways -
>> > PQL is a way to acknowledge these similarities and turn them into a
>> selling
>> > point instead.
>> >
>> > Andrés
>> > ___
>> > 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 mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Javier de la Rosa
http://versae.es
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] 1.5.M02 - JVM BootStrapper Issues

2011-11-05 Thread Chris Gioran
This issue was unintentionally introduced along with some changes
needed for better control and output from the windows wrapper. It was
a regression that has now been fixed. I would suggest either

- waiting for the next release, or

- if you are feeling adventurous, download a snapshot windows build
(http://neo4j.org/download/), extract
bin/windows-service-wrapper-3-SNAPSHOT.jar, rename that to
windows-service-wrapper-2.jar and replace the existing jar under bin/
in your current installation - the important thing is for the new jar
to have the same filename as the old one. That should fix all issues
that you have.

As a side note, i would really appreciate if you confirmed that your
configuration runs with a SNAPSHOT build.

thanks,
CG

On Sat, Nov 5, 2011 at 8:33 AM, Peter Neubauer
 wrote:
> Romiko,
> this is probably linked to the same issue,
> https://github.com/neo4j/packaging/issues/2
>
> Cheers,
>
> /peter neubauer
>
> GTalk:      neubauer.peter
> Skype       peter.neubauer
> Phone       +46 704 106975
> LinkedIn   http://www.linkedin.com/in/neubauer
> Twitter      http://twitter.com/peterneubauer
>
> http://www.neo4j.org              - NOSQL for the Enterprise.
> http://startupbootcamp.org/    - Öresund - Innovation happens HERE.
>
>
>
> On Thu, Nov 3, 2011 at 4:07 PM, Romiko Derbynew
>  wrote:
>> Hi Guys,
>>
>> I have downloaded the latest Community edition and notice these three custom 
>> lines of code causing the Neo4J server not to start up:
>>
>> wrapper.java.additional.1=-d64
>> wrapper.java.additional.1=-server
>> wrapper.java.additional.1=-Xss2048k
>>
>> With the previous version, they worked fine. They live at the bottom of the 
>> neo4j-wrapper.conf
>>
>> Error I get is.
>> java.lang.IllegalArgumentException
>>        at java.lang.ProcessImpl.(Unknown Source)
>>        at java.lang.ProcessImpl.start(Unknown Source)
>>        at java.lang.ProcessBuilder.start(Unknown Source)
>>        at java.lang.Runtime.exec(Unknown Source)
>>        at 
>> org.neo4j.wrapper.ServerProcessConsole.doStart(ServerProcessConsole.j
>> ava:39)
>>        at org.neo4j.wrapper.ServerProcess.(ServerProcess.java:116)
>>        at 
>> org.neo4j.wrapper.ServerProcessConsole.(ServerProcessConsole.ja
>> va:29)
>>        at 
>> org.neo4j.wrapper.NeoServiceWrapper.launchAsConsoleApp(NeoServiceWrap
>> per.java:48)
>>        at org.neo4j.wrapper.NeoServiceWrapper.main(NeoServiceWrapper.java:35)
>>
>> Is this expected, since I am sure the JVM should support adding these 
>> additional parameters?
>>
>> I want these in here, so I can always ensure it is 64bit, server mode with a 
>> stack size of 2048k
>>
>>
>> ___
>> 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 mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] SDG 2.0.0.M1 cross-store does not work properly

2011-11-05 Thread Michael Hunger
March,

could you try to test this on snapshot?

I solved an issue regarding that.

I'll add the test you mentioned as well

Thanks for the feedback.

Michael

mobile mail please excuse brevity and typos

Am 04.11.2011 um 23:00 schrieb Marcin Zasepa :

> Hi guys,
> i just migrated from SDG 1.1 to 2.0.0.M1 and I am facing problem with
> cross-store functionality. I have some entities which are partially stored
> in Neo and partially in rdbms. Everything works ok so far entity class has
> only primitive members or sets of other entities mapped using @RelatedTo
> annotation. Problems begin if I have one entity /A/ with partial=true which
> refers with @OneToMany another entity /B/ which is "pure" JPA entity. Trying
> to save entity *A *i get an exception: "Type class B is neither a
> @NodeEntity nor a @RelationshipEntity".This kind of mappings worked properly
> with SDG 1.1. In order to reproduce this problem in environment independent
> from my application i add simple relation to the User test class in
> spring-data-neo4j-cross-store tests: 
> @Entity
> @NodeEntity(partial = true)
> public class User {
>   .
>  @OneToMany(mappedBy="user")
>private Set locations;
> }
> , where Location class is defined as follows:
> @Entity
> @Table(name = "LOCATION")
> public class Location {
> 
>@Id
>@GeneratedValue(strategy = GenerationType.AUTO)
>@Column(name = "id")
>private Long id;
>
>@ManyToOne
>@JoinColumn(name="userId")
>private User user;
>
> }
> 
> Running ReccomendationTest after this changes, causes that the first test
> fails with an exception:
> org.springframework.data.neo4j.mapping.InvalidEntityTypeException: Type
> class org.springframework.data.neo4j.partial.Location is neither a
> @NodeEntity nor a @RelationshipEntity. What is even more interesting is that
> it happens only to the first run test, that is why two other test are not
> failing but if i invoke only one test for example the second one:
> jpaUserCanHaveGraphProperties then it fails with the same exception. 
> Could you have a look on that and let me know if I am something changed in
> SDG 2.0 or it is indeed bug.
> Thanks in advance! Greets.
> 
> --
> View this message in context: 
> http://neo4j-community-discussions.438527.n3.nabble.com/SDG-2-0-0-M1-cross-store-does-not-work-properly-tp3481372p3481372.html
> Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
> ___
> 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] Node Id generation deadlock

2011-11-05 Thread Rick Bullotta
Oh, and one more benefit - if you want to implement a distributed/sharded 
storage engine, this abstraction through a "write queue" makes it much, much 
simpler and more transparent to the application.


From: user-boun...@lists.neo4j.org [user-boun...@lists.neo4j.org] On Behalf Of 
Rick Bullotta [rick.bullo...@thingworx.com]
Sent: Saturday, November 05, 2011 11:24 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] Node Id generation deadlock

FWIW, you might be better off "pipelining" these writes through a single worker 
thread/queue.  It helps with a few performance issues:  1) you can avoid 
synchronization concerns 2) you can manage "block writes" (e.g. a number of 
writes in a single transaction) more easily and 3) you can (if you choose) 
implement throttling/queueing to support burst mode scenarios where the # 
requests to write data exceed your ability to process them (and to provide 
responsiveness for queries).

This is what we do with our activity stream engine in ThingWorx.  Note that the 
same applies for deleting entries - we try to do "bulk deletes" as well.




From: user-boun...@lists.neo4j.org [user-boun...@lists.neo4j.org] On Behalf Of 
Mattias Persson [matt...@neotechnology.com]
Sent: Saturday, November 05, 2011 9:14 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] Node Id generation deadlock

You'd have to go with another solution then. Is your application this
critical to write throughput or are you just thinking ahead and making sure
that it some day might need to support an amount of write throughput?

2011/11/3 Yaniv Ben Yosef 

> Hi,
>
> I've also been wondering about this subject.
> According to the Neo4J design guide (
> http://wiki.neo4j.org/content/Design_Guide) the factory node and id
> generator patterns are the way to implement sequential ID generation.
> However, according to this thread, it sounds like in a multi-threaded
> environment I have one of two choices:
> 1. lock the factory node. However this will force transaction
> serialization. That's not practical in my app.
> 2. reducing the granularity of the transactions - in the sense that each
> transaction should only contain one node creation (of the same type, i.e.
> uses the same factory node). That's not practical for me either, because in
> several cases I would like to create more than one node in the same
> transaction.
> Since the design guide recommends the factory node pattern, I'm wondering
> if there's anything I'm missing here, or that I should just avoid this
> pattern and use some other ID generation mechanism.
>
> Thanks,
> Yaniv
>
>
> On Thu, Nov 3, 2011 at 11:13 AM, Mattias Persson
> wrote:
>
> > 2011/11/3 Cres 
> >
> > > This solution would have been ok if I had only one node created from
> that
> > > factory in each transaction.
> > >
> > > It doesn't matter... after factory.setProperty is run that transaction
> > has
> > got a write lock on that factory node which is held until the transaction
> > committs. The benefit you get from my proposal would be that you make
> sure
> > you read the correct value.
> >
> >
> > > however, as shown in the sample code I posted in the original message,
> I
> > > have multiple nodes created in one transaction, and multiple such
> > > transactions in multiple threads.
> > > So while the creation of the actual nodes will of course be serialized,
> > one
> > > thread's transaction will have to wait for the other thread's
> transaction
> > > to
> > > finish completely, and so if the first thread has some processing to do
> > > between the creation of the first and second nodes, the other third
> won't
> > > be
> > > able to create its two nodes in the meanwhile, because the first thread
> > > will
> > > have the lock on the factory node until the entire transaction
> completes.
> > >
> > > I'm looking for a way to do this having the nodes creation serialized
> but
> > > without having the entire transactions serialized, possibly by somehow
> > > releasing the lock on the factory node in mid-transaction, or by any
> > other
> > > method.
> > >
> > > Thanks again,
> > > Ran.
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://neo4j-community-discussions.438527.n3.nabble.com/Node-Id-generation-deadlock-tp3473118p3476498.html
> > > Sent from the Neo4j Community Discussions mailing list archive at
> > > Nabble.com.
> > > ___
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> > >
> >
> >
> >
> > --
> > Mattias Persson, [matt...@neotechnology.com]
> > Hacker, Neo Technology
> > www.neotechnology.com
> > ___
> > 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/l

Re: [Neo4j] Node Id generation deadlock

2011-11-05 Thread Rick Bullotta
FWIW, you might be better off "pipelining" these writes through a single worker 
thread/queue.  It helps with a few performance issues:  1) you can avoid 
synchronization concerns 2) you can manage "block writes" (e.g. a number of 
writes in a single transaction) more easily and 3) you can (if you choose) 
implement throttling/queueing to support burst mode scenarios where the # 
requests to write data exceed your ability to process them (and to provide 
responsiveness for queries).

This is what we do with our activity stream engine in ThingWorx.  Note that the 
same applies for deleting entries - we try to do "bulk deletes" as well.




From: user-boun...@lists.neo4j.org [user-boun...@lists.neo4j.org] On Behalf Of 
Mattias Persson [matt...@neotechnology.com]
Sent: Saturday, November 05, 2011 9:14 AM
To: Neo4j user discussions
Subject: Re: [Neo4j] Node Id generation deadlock

You'd have to go with another solution then. Is your application this
critical to write throughput or are you just thinking ahead and making sure
that it some day might need to support an amount of write throughput?

2011/11/3 Yaniv Ben Yosef 

> Hi,
>
> I've also been wondering about this subject.
> According to the Neo4J design guide (
> http://wiki.neo4j.org/content/Design_Guide) the factory node and id
> generator patterns are the way to implement sequential ID generation.
> However, according to this thread, it sounds like in a multi-threaded
> environment I have one of two choices:
> 1. lock the factory node. However this will force transaction
> serialization. That's not practical in my app.
> 2. reducing the granularity of the transactions - in the sense that each
> transaction should only contain one node creation (of the same type, i.e.
> uses the same factory node). That's not practical for me either, because in
> several cases I would like to create more than one node in the same
> transaction.
> Since the design guide recommends the factory node pattern, I'm wondering
> if there's anything I'm missing here, or that I should just avoid this
> pattern and use some other ID generation mechanism.
>
> Thanks,
> Yaniv
>
>
> On Thu, Nov 3, 2011 at 11:13 AM, Mattias Persson
> wrote:
>
> > 2011/11/3 Cres 
> >
> > > This solution would have been ok if I had only one node created from
> that
> > > factory in each transaction.
> > >
> > > It doesn't matter... after factory.setProperty is run that transaction
> > has
> > got a write lock on that factory node which is held until the transaction
> > committs. The benefit you get from my proposal would be that you make
> sure
> > you read the correct value.
> >
> >
> > > however, as shown in the sample code I posted in the original message,
> I
> > > have multiple nodes created in one transaction, and multiple such
> > > transactions in multiple threads.
> > > So while the creation of the actual nodes will of course be serialized,
> > one
> > > thread's transaction will have to wait for the other thread's
> transaction
> > > to
> > > finish completely, and so if the first thread has some processing to do
> > > between the creation of the first and second nodes, the other third
> won't
> > > be
> > > able to create its two nodes in the meanwhile, because the first thread
> > > will
> > > have the lock on the factory node until the entire transaction
> completes.
> > >
> > > I'm looking for a way to do this having the nodes creation serialized
> but
> > > without having the entire transactions serialized, possibly by somehow
> > > releasing the lock on the factory node in mid-transaction, or by any
> > other
> > > method.
> > >
> > > Thanks again,
> > > Ran.
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://neo4j-community-discussions.438527.n3.nabble.com/Node-Id-generation-deadlock-tp3473118p3476498.html
> > > Sent from the Neo4j Community Discussions mailing list archive at
> > > Nabble.com.
> > > ___
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> > >
> >
> >
> >
> > --
> > Mattias Persson, [matt...@neotechnology.com]
> > Hacker, Neo Technology
> > www.neotechnology.com
> > ___
> > 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
>



--
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
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] Cypher->Pickle?

2011-11-05 Thread Nigel Small
> newbies may find it helpful to start with something they already know.
One problem with this is that it could invoke a tendency to try to map
relational concepts onto a graph db. The two types of database are
fundamentally different at the lowest level and if one starts off by
thinking "where do I put my 'tables'?" they are only heading down the wrong
path. I mentioned a while back that I felt designing a graph database is
more akin to OO design that to relational design. Maybe we should stop
using the word "database"?? :-P
*
*
*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: ni...@nigelsmall.name
MSN: nasm...@live.co.uk
Skype: technige
Twitter: @technige 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 5 November 2011 14:03, Axel Morgner  wrote:

> People already familiar with graphs seem to love the original Cypher
> syntax while newbies may find it helpful to start with something they
> already know.
>
> What about letting both coexist peacefully?
>
> Axel
>
>
> Am 05.11.2011 14:29, schrieb Andres Taylor:
> > On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
> >> I really don't want Cypher to pander to SQL. Cypher is about graph
> > matching and should be awesome at it
> >
> > PQL isn't any different in this aspect. Mattias' ascii-art is still the
> way
> > to describe your pattern. Cypher is already very like SQL in many ways -
> > PQL is a way to acknowledge these similarities and turn them into a
> selling
> > point instead.
> >
> > Andrés
> > ___
> > 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 mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] Cypher->Pickle?

2011-11-05 Thread Axel Morgner
People already familiar with graphs seem to love the original Cypher 
syntax while newbies may find it helpful to start with something they 
already know.

What about letting both coexist peacefully?

Axel


Am 05.11.2011 14:29, schrieb Andres Taylor:
> On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
>> I really don't want Cypher to pander to SQL. Cypher is about graph
> matching and should be awesome at it
>
> PQL isn't any different in this aspect. Mattias' ascii-art is still the way
> to describe your pattern. Cypher is already very like SQL in many ways -
> PQL is a way to acknowledge these similarities and turn them into a selling
> point instead.
>
> Andrés
> ___
> 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] Cypher->Pickle?

2011-11-05 Thread Andres Taylor
On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
>
> I really don't want Cypher to pander to SQL. Cypher is about graph
matching and should be awesome at it

PQL isn't any different in this aspect. Mattias' ascii-art is still the way
to describe your pattern. Cypher is already very like SQL in many ways -
PQL is a way to acknowledge these similarities and turn them into a selling
point instead.

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


Re: [Neo4j] Node Id generation deadlock

2011-11-05 Thread Mattias Persson
You'd have to go with another solution then. Is your application this
critical to write throughput or are you just thinking ahead and making sure
that it some day might need to support an amount of write throughput?

2011/11/3 Yaniv Ben Yosef 

> Hi,
>
> I've also been wondering about this subject.
> According to the Neo4J design guide (
> http://wiki.neo4j.org/content/Design_Guide) the factory node and id
> generator patterns are the way to implement sequential ID generation.
> However, according to this thread, it sounds like in a multi-threaded
> environment I have one of two choices:
> 1. lock the factory node. However this will force transaction
> serialization. That's not practical in my app.
> 2. reducing the granularity of the transactions - in the sense that each
> transaction should only contain one node creation (of the same type, i.e.
> uses the same factory node). That's not practical for me either, because in
> several cases I would like to create more than one node in the same
> transaction.
> Since the design guide recommends the factory node pattern, I'm wondering
> if there's anything I'm missing here, or that I should just avoid this
> pattern and use some other ID generation mechanism.
>
> Thanks,
> Yaniv
>
>
> On Thu, Nov 3, 2011 at 11:13 AM, Mattias Persson
> wrote:
>
> > 2011/11/3 Cres 
> >
> > > This solution would have been ok if I had only one node created from
> that
> > > factory in each transaction.
> > >
> > > It doesn't matter... after factory.setProperty is run that transaction
> > has
> > got a write lock on that factory node which is held until the transaction
> > committs. The benefit you get from my proposal would be that you make
> sure
> > you read the correct value.
> >
> >
> > > however, as shown in the sample code I posted in the original message,
> I
> > > have multiple nodes created in one transaction, and multiple such
> > > transactions in multiple threads.
> > > So while the creation of the actual nodes will of course be serialized,
> > one
> > > thread's transaction will have to wait for the other thread's
> transaction
> > > to
> > > finish completely, and so if the first thread has some processing to do
> > > between the creation of the first and second nodes, the other third
> won't
> > > be
> > > able to create its two nodes in the meanwhile, because the first thread
> > > will
> > > have the lock on the factory node until the entire transaction
> completes.
> > >
> > > I'm looking for a way to do this having the nodes creation serialized
> but
> > > without having the entire transactions serialized, possibly by somehow
> > > releasing the lock on the factory node in mid-transaction, or by any
> > other
> > > method.
> > >
> > > Thanks again,
> > > Ran.
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://neo4j-community-discussions.438527.n3.nabble.com/Node-Id-generation-deadlock-tp3473118p3476498.html
> > > Sent from the Neo4j Community Discussions mailing list archive at
> > > Nabble.com.
> > > ___
> > > Neo4j mailing list
> > > User@lists.neo4j.org
> > > https://lists.neo4j.org/mailman/listinfo/user
> > >
> >
> >
> >
> > --
> > Mattias Persson, [matt...@neotechnology.com]
> > Hacker, Neo Technology
> > www.neotechnology.com
> > ___
> > 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
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] Cypher->Pickle?

2011-11-05 Thread Jim Webber
+1 I love Cypher's ASCII art, and Josh's idea of drawing Cypher inside a 
whiteboarded graph is wonderful.

I really don't want Cypher to pander to SQL. Cypher is about graph matching and 
should be awesome at it - its duty to us newbies is simply to be humane not 
identical to what I (think I) already know.

Jim

On 5 Nov 2011, at 03:48, jadell wrote:

> 
> Mattias Persson-2 wrote:
>> 
>> 2011/11/4 maxdemarzi 
>> I'd say the strongest part of Cypher is the "ascii art" pattern where you
>> clearly see what you're querying for, right there and then without having
>> to parse it into a graph into your head. Removing that would reduce my
>> interest in this language significantly.
>> 
> 
> This! A thousand times this! Whenever I'm trying to explain how you find
> connected information without joins, people's eyes tend to glaze over until
> I a) draw the graph on the whiteboard, b) write out the Cypher query
> *directly inside the graph*. That's the "no f-ing way!" moment for most
> people to see the power of graphs and graph query languages. 
> 
> -- Josh Adell
> 
> --
> View this message in context: 
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481871.html
> Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
> ___
> 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] Cypher question

2011-11-05 Thread jschweigl
Stupid me. Sorry. I should have copypasted your query. Yes, without the path
assignment it works.

Thanks a lot!

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Cypher-question-tp3479960p3482176.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] Cypher question

2011-11-05 Thread Andres Taylor
Did you try the query I gave you? The problem is not that you are returning
p, it's that you ask Cypher to create a path with nulls in it. Just remove
the p= in the beginning of the MATCH clause, and you should be good to go.

Andrés

On Sat, Nov 5, 2011 at 8:45 AM, jschweigl  wrote:

> Good point. I'd believe that thinking of a single node as a degenerated
> path
> wouldn't be that wrong either. However, even returning just the callee
> (which is what I wanted anyways) brings no relief, with the relationship
> direction having no influence:
>
>
> 08:42:33,150 GraphQuery.java 81 INFO   - START
> callee=node:node_auto_index('type:*Service') MATCH
> p=(caller)-[r?:CALLS]->(callee) WHERE r IS NULL RETURN callee
>
> Exception in thread "main" java.lang.AssertionError: assertion failed
>at scala.Predef$.assert(Predef.scala:89)
>at org.neo4j.cypher.PathImpl.(PathImpl.scala:34)
>at
>
> org.neo4j.cypher.pipes.NamedPathPipe$$anonfun$foreach$1.apply(NamedPathPipe.scala:50)
>at
>
> org.neo4j.cypher.pipes.NamedPathPipe$$anonfun$foreach$1.apply(NamedPathPipe.scala:39)
>at
>
> org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(MatchPipe.scala:37)
>at
>
> org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(MatchPipe.scala:37)
>at
>
> scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
>at scala.collection.immutable.List.foreach(List.scala:45)
>at
>
> org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1.apply(MatchPipe.scala:37)
>at
>
> org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1.apply(MatchPipe.scala:36)
>at
>
> org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(StartPipe.scala:36)
>at
>
> org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(StartPipe.scala:35)
>at scala.collection.Iterator$class.foreach(Iterator.scala:652)
>at
>
> scala.collection.JavaConversions$JIteratorWrapper.foreach(JavaConversions.scala:573)
>at
> scala.collection.IterableLike$class.foreach(IterableLike.scala:73)
>at
>
> scala.collection.JavaConversions$JIterableWrapper.foreach(JavaConversions.scala:587)
>at
>
> org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.scala:35)
>at
>
> org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.scala:34)
>at
> org.neo4j.cypher.pipes.ParameterPipe.foreach(ParameterPipe.scala:27)
>at org.neo4j.cypher.pipes.StartPipe.foreach(StartPipe.scala:34)
>at org.neo4j.cypher.pipes.MatchPipe.foreach(MatchPipe.scala:36)
>at
> org.neo4j.cypher.pipes.NamedPathPipe.foreach(NamedPathPipe.scala:39)
>at
> scala.collection.TraversableLike$class.filter(TraversableLike.scala:212)
>at org.neo4j.cypher.pipes.Pipe.filter(Pipe.scala:31)
>at org.neo4j.cypher.pipes.FilterPipe.foreach(FilterPipe.scala:30)
>at
> org.neo4j.cypher.pipes.TransformPipe.foreach(TransformPipe.scala:38)
>at
> org.neo4j.cypher.pipes.ColumnFilterPipe.foreach(ColumnFilterPipe.scala:35)
> at
> scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:48)
>at
> scala.collection.mutable.ListBuffer.$plus$plus$eq(ListBuffer.scala:128)
>at
> scala.collection.TraversableOnce$class.toList(TraversableOnce.scala:242)
>at org.neo4j.cypher.pipes.Pipe.toList(Pipe.scala:31)
>at
>
> org.neo4j.cypher.ExecutionResult$class.dumpToString(ExecutionResult.scala:69)
>at
>
> org.neo4j.cypher.pipes.ColumnFilterPipe.dumpToString(ColumnFilterPipe.scala:25)
>at sandbox.GraphQuery.doQuery(GraphQuery.java:86)
>at sandbox.GraphQuery.run(GraphQuery.java:74)
>at sandbox.GraphQuery.main(GraphQuery.java:30)
>
>
> --
> View this message in context:
> http://neo4j-community-discussions.438527.n3.nabble.com/Cypher-question-tp3479960p3482144.html
> Sent from the Neo4j Community Discussions mailing list archive at
> Nabble.com.
> ___
> 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] Cypher question

2011-11-05 Thread jschweigl
Good point. I'd believe that thinking of a single node as a degenerated path
wouldn't be that wrong either. However, even returning just the callee
(which is what I wanted anyways) brings no relief, with the relationship
direction having no influence:


08:42:33,150 GraphQuery.java 81 INFO   - START
callee=node:node_auto_index('type:*Service') MATCH
p=(caller)-[r?:CALLS]->(callee) WHERE r IS NULL RETURN callee

Exception in thread "main" java.lang.AssertionError: assertion failed
at scala.Predef$.assert(Predef.scala:89)
at org.neo4j.cypher.PathImpl.(PathImpl.scala:34)
at
org.neo4j.cypher.pipes.NamedPathPipe$$anonfun$foreach$1.apply(NamedPathPipe.scala:50)
at
org.neo4j.cypher.pipes.NamedPathPipe$$anonfun$foreach$1.apply(NamedPathPipe.scala:39)
at
org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(MatchPipe.scala:37)
at
org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(MatchPipe.scala:37)
at
scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59)
at scala.collection.immutable.List.foreach(List.scala:45)
at
org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1.apply(MatchPipe.scala:37)
at
org.neo4j.cypher.pipes.MatchPipe$$anonfun$foreach$1.apply(MatchPipe.scala:36)
at
org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(StartPipe.scala:36)
at
org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1$$anonfun$apply$1.apply(StartPipe.scala:35)
at scala.collection.Iterator$class.foreach(Iterator.scala:652)
at
scala.collection.JavaConversions$JIteratorWrapper.foreach(JavaConversions.scala:573)
at scala.collection.IterableLike$class.foreach(IterableLike.scala:73)
at
scala.collection.JavaConversions$JIterableWrapper.foreach(JavaConversions.scala:587)
at
org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.scala:35)
at
org.neo4j.cypher.pipes.StartPipe$$anonfun$foreach$1.apply(StartPipe.scala:34)
at org.neo4j.cypher.pipes.ParameterPipe.foreach(ParameterPipe.scala:27)
at org.neo4j.cypher.pipes.StartPipe.foreach(StartPipe.scala:34)
at org.neo4j.cypher.pipes.MatchPipe.foreach(MatchPipe.scala:36)
at org.neo4j.cypher.pipes.NamedPathPipe.foreach(NamedPathPipe.scala:39)
at 
scala.collection.TraversableLike$class.filter(TraversableLike.scala:212)
at org.neo4j.cypher.pipes.Pipe.filter(Pipe.scala:31)
at org.neo4j.cypher.pipes.FilterPipe.foreach(FilterPipe.scala:30)
at org.neo4j.cypher.pipes.TransformPipe.foreach(TransformPipe.scala:38)
at
org.neo4j.cypher.pipes.ColumnFilterPipe.foreach(ColumnFilterPipe.scala:35)
at 
scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:48)
at 
scala.collection.mutable.ListBuffer.$plus$plus$eq(ListBuffer.scala:128)
at 
scala.collection.TraversableOnce$class.toList(TraversableOnce.scala:242)
at org.neo4j.cypher.pipes.Pipe.toList(Pipe.scala:31)
at
org.neo4j.cypher.ExecutionResult$class.dumpToString(ExecutionResult.scala:69)
at
org.neo4j.cypher.pipes.ColumnFilterPipe.dumpToString(ColumnFilterPipe.scala:25)
at sandbox.GraphQuery.doQuery(GraphQuery.java:86)
at sandbox.GraphQuery.run(GraphQuery.java:74)
at sandbox.GraphQuery.main(GraphQuery.java:30)


--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Cypher-question-tp3479960p3482144.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user


Re: [Neo4j] Cypher DSL and result mapping

2011-11-05 Thread Rickard Öberg
On 11/5/11 24:41 , Daniel Yokomizo wrote:
> Is there a raw type if nothing is provided (e.g. Map  with
> alias,result)? With something  like this the programmer can use any mapping
> tool after. But would be nice to have json support.

The Projection class does not perform the query (the results are passed 
into it), so if you want the raw Iterable, simply don't use 
Projection. Support for JSON is a great idea though!

/Rickard

-- 
Rickard Öberg
Developer
Neo Technology
Twitter: @rickardoberg, Skype: rickardoberg
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user