2010/11/5 serff
>
> Another question while I'm at it: The new indexing service in 1.2 seems to
> want you to create what I'll call a namespace for each index. Would you
> create a single namespace for all of this data or separate namespaces for
> each datatype? i.e. have a "main" index or a "t
Hi Andrés,
> In regards to your database size problem, unfortunately, I can't offer a
> clean and easy solution. The store files grow as more data is added, but
> doesn't shrink when you remove data. There are technical reasons for this,
> but for you, it means that you either have to live with a d
Honestly, like Rick, I do tend to use a type parameter. One advantage is
that other tools (like neoclipse for example) can visualize the generic
graph and color code, or add icons, based on that parameters.
For indexing, I tend to only add lucene indexes for identity properties
(like a name or id)
And actually, the fix made it into the 1.2.M03 milestone, so you can use
that. Thanks a lot for reporting the problem!
/anders
2010-11-05 08:11, Balazs E. Pataki skrev:
> Thank you very much for the quick response and quick fix!
> ---
> balazs
>
> On 11/4/10 8:11 PM, Mattias Persson wrote:
>> I
Craig,
Thank your for you interesting approach. I had not thought of modeling it
so that the actual graph infers type.
After my second question I sent, I thought of another way to "type" the
nodes and it is by using separate index namespaces for each type. So if I
want to find a truck, i look i
Hi all,
Hopefully most of you are familiar with the traversal framework that was
introduced in 1.1. It's powerful and provides for reusable traversal
descriptions. It has some flaws though, and I would like to discuss one of
them here.
The traversal framework has this concept of pruning, which ba
To add to Craig's excellent inputs, my advice is to (almost) always "mark"
your nodes with a type property. There are some really cool scenarios where
you can use relatively generic relationships to semantically link seemingly
unrelated entities (e.g. tagging), but it is still useful to know what
I can make a few comments about modeling this kind of data.
While it is an option to use type="trunk" properties to type your nodes, and
in fact I do that a lot myself, another very common approach is to deduce
the type from the incoming relationships. Then everything is about the graph
structure.
I'm not actually tracking this kind of info...it is a mock up of the real
data I'm modeling, but it fits inline with what i'm trying to do. Maybe you
could instead share some insights as to how you model your data at
ThingWorx?
Thanks.
Andrew
--
View this message in context:
http://neo4j-user-
Well, you could just use our ThingWorx platform (built with Neo4J inside)...
;-)
Vehicle tracking and supply chain traceability is a key area for us.
Contact me off list if interested. We have a demo of almost exactly that
scenario.
Rick Bullotta
ThingWorx
http://www.thingworx.com
-Origin
Another question while I'm at it: The new indexing service in 1.2 seems to
want you to create what I'll call a namespace for each index. Would you
create a single namespace for all of this data or separate namespaces for
each datatype? i.e. have a "main" index or a "truck", "car", "person",
"lo
Hello all, I'm having difficulty trying to decide on the best way to model
my data in Neo4j. I'm hoping if I describe what I'm trying to do, maybe you
guys can help me figure out the best way to model the data in neo4j.
For starters, I'll have something like a document that was written about one
The first time is a promise. The second, a confirmation. But it's not until
the third time you follow through on cleaning your room that you can claim it
as a habit.
We're feeling good about having a milestone release habit. Regular releases
keep us mindful of always working towards delivering
Thank you very much for the quick response and quick fix!
---
balazs
On 11/4/10 8:11 PM, Mattias Persson wrote:
> I just fixed it, unfortunately it won't make it into the M03... but it's
> available in latest SNAPSHOT at least!
>
> 2010/11/4 Balazs E. Pataki
>
>> Great, thanks!
>> ---
>> balazs
>>
14 matches
Mail list logo
