Let's say you have persons and organisations in your graph... they both have
the name property. Now you could index both persons and organisations in
the same index with the name property, but then you'd get mixed results
back. Or you could invent some key convention, like org_name and
person_name
Interesting. That's assuming a person and an organization can share the same
name. Maybe an edge case in this example, but I can understand. Thanks.
Aseem
On Thu, May 5, 2011 at 12:58 AM, Mattias Persson
matt...@neotechnology.comwrote:
Let's say you have persons and organisations in your
Another view of things would be to say that ideally there should be no first
class type on either relationships or nodes, since that is a domain specific
concept (as Neils says he wants two types, but Rick wants one, and some
object models type nodes by relating them to a separate node
And,
of course different indexes can be backed by totally different Index
Providers. Lucene, Redis, Hadoop ...
Cheers,
/peter neubauer
GTalk: neubauer.peter
Skype peter.neubauer
Phone +46 704 106975
LinkedIn http://www.linkedin.com/in/neubauer
Twitter
This is how we use it, for performance, since some data will be much more
dense than other data, we don't want the index lookup of the sparse data to
be impacted by the dense data, we make separate indexes.
On Thu, May 5, 2011 at 3:47 PM, Peter Hunsberger peter.hunsber...@gmail.com
wrote:
On
Hi,
Anothor bug like feature I just found. :-)
Node#getRelationships() return an Iterablle, from which I can get an
Iterator. This Iterator (actually IntArrayIterator) however doesn't
implement the full Iterator interface as it throws an
UnsupportedOperationException() when remove() is called
I think the basic confusion surrounding this issue stems from the term
RelationshipType. It is not a type, but just a key to the relationships value
store (resulting in nodes).
When you consider a node as a consisting of two maps, one from property keys to
property values and one from the
Am 05.05.2011 19:19, schrieb Rick Bullotta:
In general, I think it's a good idea to avoid strings as types for a whole
host of reasons (performance, future renaming/refactoring, etc.).
Having type-ids for performance reasons instead of type-strings is okay,
but because of future
Example: Today I call them cars, but tomorrow I simply want to call them
deprecatedTransporationVehicles. If I have used an integral type-id, I can
make this change trivially at the display level. If I have used strings, I
cannot...
-Original Message-
From:
Relationship-Types are already stored separately and just referenced via an ID,
so renaming them should be something the Neo4j store should offer.
Cheers
Michael
Am 05.05.2011 um 19:46 schrieb Rick Bullotta:
Example: Today I call them cars, but tomorrow I simply want to call them
I agree it can be valuable to assign a type to a node. In my own work I do
that, but we may have very different needs with regards to typing. In the
application I have built, I use relationships to make nodes an instance of one
or more types, while node types can be subtype of one or more
I solved the node typing problem using
http://wiki.neo4j.org/content/Design_Guide#Subreferences . This worked out
well for starting traversals over all nodes of a particular type. Many of my
traversal problems can be solved easily with a Pathfinder initialized with
two subreference nodes to get
Hi there,
could this also be an issue of IDs being reclaimed and the Dashboard not
reporting the actual number of relationships, but the number of relationship
IDs in use, which is greater when relationships have e.g. been deleted and
new ones inserted. Is there any concrete evidence of data
Nils that sounds interesting do you share the type mapping code for scala
somewhere?
Michael
Sent from my iBrick4
Am 05.05.2011 um 22:22 schrieb Niels Hoogeveen pd_aficion...@hotmail.com:
I agree it can be valuable to assign a type to a node. In my own work I do
that, but we may have
Uncommitted?
-Original Message-
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
Behalf Of Bobby Norton
Sent: Thursday, May 05, 2011 4:21 PM
To: user@lists.neo4j.org
Subject: [Neo4j] Relationships missing after restart?
Under what circumstances would I expect
Sorry meant Niels of course ;)
Sent from my iBrick4
Am 05.05.2011 um 22:35 schrieb Michael Hunger
michael.hun...@neotechnology.com:
Nils that sounds interesting do you share the type mapping code for scala
somewhere?
Michael
Sent from my iBrick4
Am 05.05.2011 um 22:22 schrieb
Hi Michael,
I do not share the type mapping code I just described, at least not yet. I'd
like to launch a product using these techniques first and maybe somewhere down
the line decide to make it open source, but for now I am keeping this work to
myself, to at least have some competitive edge.
I suspected it was either a dashboard issue or perhaps an indexing problem
as we weren't missing any data. I've ruled out the indexes, so I guess we
could call that a bug in the admin UI. As Peter alluded to, we encountered
this after heavy churn where thousands of relationships were being rapidly
18 matches
Mail list logo
