Yeah, that helps. Thanks a lot
Francis,
we have not released the surrounding components that are not contained
in the APOC as compliant snapshots. That means, you should check out
trunk from svn for the interesting components with e.g.
svn co https://svn.neo4j.org/components/neo-rdf/trunk/ neo-rdf
Why do you need to set your own ID's? You can use the relationship's
built-in as your index key (it is guaranteed to be unique) and
getRelationshipByID to retrieve the relationship. You'd need to very
slightly extend the LuceneIndex stuff to deal with relationships, but it
shouldn't be difficult.
2010/1/29 Anton Popov :
> And as far as I can see there is no way to set my own id'es for Relations?
> Only Nodes has such functionality - am I right?
No you can't and "setting your own ids" shouldn't be misused since the
id of a node is actually relative to where in the file (on disc) it is
locate
> > Is there any recommendation on when to use additional node/relationship
> > connections versus additional node properties?
>
> It depends of use case but go with relationships if it "enriches" the
> graph with information that makes sense.
>
And this related to another aspect, based on the bal
Now it's available at
http://m2.neo4j.org/org/neo4j/neo4j-index/1.0-SNAPSHOT/neo4j-index-1.0-20100129.143758-4.jar
2010/1/29 Mattias Persson :
> 2010/1/29 Symeon (Akis) Papadopoulos :
>>
>>> I just fixed the bug and your benchmarks run fine w/o any modification
>>> on my machine, so they should ru
And as far as I can see there is no way to set my own id'es for Relations?
Only Nodes has such functionality - am I right?
-- Forwarded message --
From: Anton Popov
Date: 2010/1/29
Subject: Re: [Neo] Relation properties
To: Neo user discussions
Hello Mattias,
Got it. Thanks.
I
2010/1/29 Symeon (Akis) Papadopoulos :
>
>> I just fixed the bug and your benchmarks run fine w/o any modification
>> on my machine, so they should run fine on your end too!
>>
> Thank you Mattias!
> So, in the end it was a neo4j-index bug? Thus I assume we don't need to
> modify our code (of cours
Tim,
Jetty is run frequently together with Jersey and Neo4j. There is no
sign of any of these Exceptions coming from Neo4j code. However, could
you please provide (maybe off-list) some example code so we can take a
look at it?
Cheers,
/peter neubauer
COO and Sales, Neo Technology
GTalk: ne
> I just fixed the bug and your benchmarks run fine w/o any modification
> on my machine, so they should run fine on your end too!
>
Thank you Mattias!
So, in the end it was a neo4j-index bug? Thus I assume we don't need to
modify our code (of course we'll take into consideration your previous
Hi,
On Wed, Jan 27, 2010 at 11:15 PM, Rick Bullotta
wrote:
> Is there any recommendation on when to use additional node/relationship
> connections versus additional node properties?
It depends of use case but go with relationships if it "enriches" the
graph with information that makes sense.
In
Hello Mattias,
Got it. Thanks.
Is there any RoadMap available?
2010/1/29 Mattias Persson
> Unfortunately you cannot index Relationships, but it's a (frquently
> requested) feature we're planning to add.
>
> 2010/1/29 Anton Popov :
> > Hello everybody,
> >
> > A related question is can I index b
I just fixed the bug and your benchmarks run fine w/o any modification
on my machine, so they should run fine on your end too!
The bug is just committed so the latest build will be available within
an hour. I see that you aren't using maven, am I right? In that case
you can download it from
http:/
Unfortunately you cannot index Relationships, but it's a (frquently
requested) feature we're planning to add.
2010/1/29 Anton Popov :
> Hello everybody,
>
> A related question is can I index both Nodes & Relations?
> As I can see LuceneIndexBatchInserter.index( long node, String key, Object
> valu
Hello everybody,
A related question is can I index both Nodes & Relations?
As I can see LuceneIndexBatchInserter.index( long node, String key, Object
value ) applies for Nodes only.
2010/1/28 Mattias Persson
> Not at all, you're not the first one to overlook that inheritance!
>
> 2010/1/28, Ant
2010/1/29 Symeon (Akis) Papadopoulos :
> Mattias Persson wrote:
>> Another problem I see is that you're having too granular transactions
>> which will slow down the insertion process quite a bit. Try grouping a
>> couple of thousands operations in one transaction and you'll see a
>> performance boo
Mattias Persson wrote:
> Another problem I see is that you're having too granular transactions
> which will slow down the insertion process quite a bit. Try grouping a
> couple of thousands operations in one transaction and you'll see a
> performance boost!
>
> FYI: I can trigger the problem you we
(Sorry for spamming you guys)
See http://wiki.neo4j.org/content/Transactions for general information
about how to manage transactions in Neo4j.
2010/1/29 Mattias Persson :
> Another problem I see is that you're having too granular transactions
> which will slow down the insertion process quite a
Another problem I see is that you're having too granular transactions
which will slow down the insertion process quite a bit. Try grouping a
couple of thousands operations in one transaction and you'll see a
performance boost!
FYI: I can trigger the problem you were having with lucene "too many
op
I see that you're not using the Neo4j BatchInserter. Your use case
could definately benefit from it. Take a look at
http://wiki.neo4j.org/content/Batch_Insert on how to use it. And since
you're using index lookups you'll have to keep most of the index in
your own HashMap or other cache (instead of
Hi,
I think neo4j seems to be a good fit for what I am trying to do but I am not
sure about a few things.
I have a requirement that I need to move data from one database to another.
There will be many client databases and they need to synchronize with a
central database, so SOME (not all data) da
20 matches
Mail list logo
