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.). We use a
special type of enum with an int "code" assigned to each enum in the
constructor (never, EVER use the ordinal() method with enums unless you want
super fragile code!). In our persistence layer, we "stamp" each node with its
type (using the .code() property of the Type enum). Code example follows:
public static enum ThingworxPrincipalTypes {
Unknown(UNKNOWN_NODE_TYPE),
User(1),
Group(2),
SuperUser(3);
private int _code;
private ThingworxPrincipalTypes(int code) {
_code = code;
}
public int code() {
return _code;
}
public static ThingworxPrincipalTypes fromCode(int code) {
for(ThingworxPrincipalTypes type :
ThingworxPrincipalTypes.values()) {
if(type.code() == code)
return type;
}
return null;
}
public static ThingworxPrincipalTypes fromNode(Node node) {
Integer code =
(Integer)node.getProperty(CommonPropertyNames.PROP_PRINCIPALTYPE,UNKNOWN_NODE_TYPE);
if(code != null) {
for(ThingworxPrincipalTypes type :
ThingworxPrincipalTypes.values()) {
if(type.code() == code)
return type;
}
}
return null;
}
}
-----Original Message-----
From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
Behalf Of Michael Hunger
Sent: Thursday, May 05, 2011 1:06 PM
To: Neo4j user discussions
Subject: Re: [Neo4j] First-class "type" property on relationships but not
nodes; why?
A minor optimization idea? Would it be sensible to use the shortstring storage
optimization for the rel-types (an perhaps node-types at some point) as well?
So if it fits within the 64 bits of a long it can be stored as such?
A more rigorous thing would be to restrict types to those criteria that they
fit into a short-string.
Just an idea
Cheers
Michael
Am 05.05.2011 um 17:51 schrieb Rick Bullotta:
> I would say that the same is true of a "type" on a node - it could be a
> significant performance optimization, depending on how properties are loaded
> vs the "node itself". If it saves a major step by not having to search
> around in property "stuff", there's an immediate advantage. Also, I suspect
> that many (most) people would store "type" properties as string(s) (we don't,
> but that's only because we've basically implemented node type as a special
> kind of enum, similar to relationship type), the various performance issues
> related to string storage/retrieval exist.
>
> Also, the very essence of a "type" on a node creates a basic sort of
> atomicity in terms of knowing what a node "represents", given only its node
> id, with no dependencies on relationships for facilitating type identity
> (though we use relationships in our model as a form of "implementation
> inheritance" similar to Tobias' comments on the subject).
>
> I really think that there are enough potential benefits to at least consider
> a native "type" concept it for the future, if for no other reason that
> uniformity of implementation, though I suspect there will be inherent
> performance optimizations and new types of traversals made possible and
> faster.
>
> The good (great) news is that the flexibility and capability of Neo4J as it
> already exists allows us to model all of these scenarios today!
>
>
> -----Original Message-----
> From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
> Behalf Of Craig Taverner
> Sent: Thursday, May 05, 2011 10:08 AM
> To: Neo4j user discussions
> Subject: Re: [Neo4j] First-class "type" property on relationships but not
> nodes; why?
>
> 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 representing a
> class).
>
> Then the addition of a type to a relationship is, in my opinion, a
> performance optimization for many graph algorithms since the traverser will
> perform well if it has 'first class' access to this information, instead of
> hitting the property store. I guess this is my take on Tobias point that the
> type is a navigational feature.
>
> Now I wonder if the traverser, and many known graph algorithms, would be
> possible to make faster or easier to code if the nodes also had first class
> types? I don't know the answer to this, but assume that if it did really
> help, it would have been done already ;-)
>
> On Thu, May 5, 2011 at 3:52 PM, Niels Hoogeveen
> <pd_aficion...@hotmail.com>wrote:
>
>>
>> The meta model component (though in need of some attention), already allows
>> the typing of a node. An important difference between the typing in the meta
>> model component and the suggestion made in this thread is the fact that a
>> node according to the meta model can have more than one type, while the
>> RelationshipType in kernel only allows one type per relationship.
>> For my modeling need, the ability to assign more than one type per node is
>> essential. Adding a singular type at kernel level would only make things
>> more confusing.
>> I would go further than what Tobias says and would say RelationshipType is
>> nothing but a name, just like various properties have names. Types would
>> require much more information, like cardinality, source/target constraints
>> etc. Those are all part of the meta model where they belong.
>>
>>> From: tobias.ivars...@neotechnology.com
>>> Date: Thu, 5 May 2011 15:33:04 +0200
>>> To: user@lists.neo4j.org
>>> Subject: Re: [Neo4j] First-class "type" property on relationships but not
>> nodes; why?
>>>
>>> The RelationshipType isn't a type. It is a navigational feature.
>>>
>>> I've slapped this link around for a few years now, every time this
>> question
>>> has been brought up:
>>> http://lists.neo4j.org/pipermail/user/2008-October/000848.html
>>>
>>> The fact that RelationshipType is a navigational feature and not a type
>>> means that there is in fact already a corresponding thing for nodes: the
>>> Indexes.
>>>
>>> But I agree that there would be things we could gain by adding a Type
>>> concept to Nodes. Such as for example better automatic indexing. But I
>> don't
>>> know what it would look like. And I want it to be clear that such a
>> feature
>>> is very different from what RelationshipType is today.
>>>
>>> Cheers,
>>> Tobias
>>>
>>> On Thu, May 5, 2011 at 10:29 AM, Aseem Kishore <aseem.kish...@gmail.com
>>> wrote:
>>>
>>>> I've found it interesting that Neo4j has a mandatory "type" property on
>>>> relationships, but not nodes. Just curious, what's the reasoning behind
>> the
>>>> design having this distinction?
>>>>
>>>> If you say "you need to know what type of relationship these two nodes
>>>> have", I would reply, "don't you also need to know what type of nodes
>> they
>>>> are, as well?"
>>>>
>>>> Similarly, if you say "because there can be many different types of
>>>> relationships", I would reply, "there can also be many different types
>> of
>>>> nodes, and in both cases, there doesn't need to be".
>>>>
>>>> A perfect example is in the documentation/tutorial: movies and actors.
>> Just
>>>> the fact that we talk about the nodes in the database as "movies" and
>>>> "actors" -- wouldn't it be helpful for the database to support that
>>>> categorization first-class?
>>>>
>>>> To be precise, it's easy for us to add a "type" property to nodes
>> ourselves
>>>> (we do in our usage), but it's not a first-class property like
>>>> relationships, where queries and traversals can easily and naturally
>>>> specify
>>>> the type or types they expect.
>>>>
>>>> Thanks!
>>>>
>>>> Aseem
>>>> _______________________________________________
>>>> Neo4j mailing list
>>>> User@lists.neo4j.org
>>>> https://lists.neo4j.org/mailman/listinfo/user
>>>>
>>>
>>>
>>>
>>> --
>>> Tobias Ivarsson <tobias.ivars...@neotechnology.com>
>>> Hacker, Neo Technology
>>> www.neotechnology.com
>>> Cellphone: +46 706 534857
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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
