2010/3/30 Niels Hoogeveen pd_aficion...@hotmail.com
MetaModelObject already has a getter (without using the word get) to
access the node.
Wrapping MetaModelObject to give it a Node-interface makes it possible to
directly write:
metalObject.setProperty(a, b)
instead of
Since no one responded yesterday, I wanted to re-emphasize that there
are probably substantial optimizations that can be made in a well-known
problem domain such as this. For example, by using pre-calculated
relevance measures for tags, and by narrowing the returned set of
Hi,
The read only version is not faster on reads compared to a writable
store. Internally the only difference is we open files in read only
mode.
The reason you get the error is that your OS does not support to place
a memory mapped region to a file (opened in read only mode) when the
region
The example of the tag library and countries/sub-divisions are not necessarily
similar. The first shows the need to model the properties of a class.
The second example shows the need to have singleton classes, which is a
different concept, and something that cannot be done out of the box, but
Hi,
I had a look at this and can not figure out why -1 is returned.
When running the kernel in normal (write) mode the return value of
number of ids in use will only be correct if all previous shutdowns
have executed cleanly. This is an optimization to reduce the time
spent in recovery
Did you make any progress with this? I could provide you with an example as
well, here goes:
GraphDatabaseService graphDb = new EmbeddedGraphDatabase( my/path );
IndexService index = new LuceneIndexService( graphDb );
// This is how to create and index a UUID for a node.
...
If it's not a very large data set (or you have enough RAM) you could keep
stuff like that in a HashMap really, that's how I do it sometimes... that
way you can get rid of that extra lookup and it'll be faster. So you insert
relationship as usual and in addition store that relationship (i.e. start
Well, these were the kind of questions I would like to get input on, what is
it that you need. But since I am a user as well as a designer of this I
guess I could go ahead and answer these questions from my perspective. I'll
do so inline.
On Wed, Mar 31, 2010 at 5:26 PM, Rick Bullotta
On 04/08/2010 03:20 AM, Johan Svensson wrote:
Hi Patrick,
Thanks for the feedback. I will have a look at this and implement
handling for disconnection and expiration of sessions.
No problem. We'll be psyched to see you roll this out.
Regarding the GC issues we are well aware of these
Your point about the cardinality restriction is a correct observation.
In fact it would be better to create a is-subdivision-of PropertyType on
sub-division and give that a range country with a cardinality of 1. Then
for each subclass of sub-division a restriction should be set, naming the
2010/4/8 Niels Hoogeveen pd_aficion...@hotmail.com
Your point about the cardinality restriction is a correct observation.
In fact it would be better to create a is-subdivision-of PropertyType on
sub-division and give that a range country with a cardinality of 1. Then
for each subclass of
Each country needs to be modeled as classes, because I want to set the
restriction that French regions (which can have different properties from
Canadian provinces) can only have a relationship with the country France, and
Canadian provinces can only have a relationship with the country
What I want to avoid
is keeping state on the server while waiting for the client to request the
next page.
You are quite right. However, I think for many use cases (e.g. generating a
paginated list of results on a webpage) it would not be necessary to store
state on the server.
That would be
Tobias Ivarsson schrieb am 08.04.2010 um 18:23:27 (+0200)
[Re: [Neo] Traversers in the REST API]:
On Wed, Apr 7, 2010 at 3:05 PM, Alastair James al.ja...@gmail.com
wrote:
when we start talking about returning 1000s of nodes in JSON over
HTTP just to get the first 10 this is clearly
Ok now I get your point! Thank you for clarifying.
Your singleton proposal could be a good idea then. Could it
potentially be a hindrance in some scenario? I mean should we have a
MetaModelClass#setSingleton(boolean) or something so that this
behaviour can be controlled?
2010/4/8, Niels
suryadev vasudev schrieb am 06.04.2010 um 23:26:35 (-0700)
[[Neo] Date effectiveness (Time Variance) implementation in Neo4J]:
We are exploring Neo4J for a resource management application.
[ straightforward requirements list without
any discernible graph specifica snipped ]
In Neo4J, we
Alastair James schrieb am 07.04.2010 um 15:53:50 (+0100)
[[Neo] How to efficiently query in Neo4J?]:
Briefly, the site consists of posts, each tagged with various
attributes, e.g. (its a travel site) location, theme, cost etc... Also
the tags are hierarchical. So, for location we have (say)
I think the best solution here is to have an instance enumeration on
MetaModelClass. Singletons are special case of an enumeration.
See:
http://www.w3.org/TR/2002/WD-owl-ref-20021112/#Enumerated
http://owl.cs.manchester.ac.uk/2007/05/api/javadoc/org/semanticweb/owl/model/OWLObjectOneOf.html
Max De Marzi Jr. schrieb am 08.04.2010 um 16:48:18 (-0500)
[Re: [Neo] How to efficiently query in Neo4J?]:
You know this is something that I think needs to be made clear...
using just the graph is not the right way to go unless you have a very
special application.
Some things are better not
As always, it really isn't that simple. Comparing cold queries is
probably not a good indicator of steady state performance, since
RDBMS's and Graph DB's have different models for file system access and
caching. Even different RDBMS's have dramatically different behaviors
in
Hi...
On 8 April 2010 22:35, Michael Ludwig mil...@gmx.de wrote:
After giving this some thought, it looks to me as if there is nothing
particularly graphy in your example. I know, most everything is a graph,
but here the data is more regular: Your hierarchical catalog of tags
immediately
As always, it really isn't that simple. Comparing cold queries is
probably not a good indicator of steady state performance, since
RDBMS's and Graph DB's have different models for file system access and
caching. Even different RDBMS's have dramatically different behaviors
in common
On 8 April 2010 21:17, Michael Ludwig mil...@gmx.de wrote:
Limiting and paging usually go hand in hand with sorting, in my
experience. Why would anyone want to page through an unsorted
collection?
Its quite possible that you might want the nodes in the order they were
found (e.g. the closest
rick.bullotta schrieb am 08.04.2010 um 15:16:11 (-0700)
[Re: [Neo] How to efficiently query in Neo4J?]:
Factor in a wide range of SLAs needed for performance vs availability
vs affordability vs scalability vs adminstration costs, and the
equation gets a whole lot more complicated.
Granted.
24 matches
Mail list logo
