Those methods will of course be more efficient if implemented in the kernel compared to iterating through all relationships if the whole relationship chain have already been loaded for that node, otherwise it will require a full iteration (or at least making sure the whole chain have been loaded). I've never found a use case for it myself and this is the first I've heard.
2011/8/1 Niels Hoogeveen <pd_aficion...@hotmail.com> > > I have two specific use cases for these methods: > I'd like to present a node with the property types (names) it has content > for and with the relationship types it has relationships for, while loading > those properties/relationships on demand (ie. click here to see details). > This can be done for properties: there is a getPropertyKeys() method, but > there is no getRelationshipTypes() method. > The other use case has to do with the Enhanced API. There I want to have > pluggable relationships and properties. With respect to relationships there > are already three implementations: the regular Relationship, SortedRelations > (which use an in-graph Btree for storage) and HyperRelationships which allow > n-ary relationships. > Every Element in Enhanced API has a getRelationships() method, much like > the getRelationships() method in Node, which should return every > relationship attached to an Element, irrespective of its implementation. > Right now the Element implementation has to perform the logic to distinguish > which relationship is used for what implementation (under the hood it all > works using normal Relationships). It would be much more elegant to iterate > over the RelationshipTypes and dispatch the getRelationships() method to the > appropriate RelationshipType implementations. That way the logic for > SortedRelationships, HyperRelationships remains in their associated classes > and is not spread around the implementation. > > Niels > > From: michael.hun...@neotechnology.com > > Date: Sun, 31 Jul 2011 23:20:50 +0200 > > To: user@lists.neo4j.org > > Subject: Re: [Neo4j] Node#getRelationshipTypes > > > > Imho it would have to iterate as well. > > > > As the type is stored with the relationship record and so can only be > accessed after having read it. > > > > It might be to have some minimal performance improvements that > relationships would not have to be fully loaded, nor put into the cache for > that. But this is always a question of the use-case. What will be done next > with those rel-types. > > > > What was the use-case for this operation again? > > > > Cheers > > > > Michael > > > > Am 31.07.2011 um 18:59 schrieb Niels Hoogeveen: > > > > > > > > Good point. > > > It could for all practical purposes even be Iterable<RelationshipType> > so they can be lazily fetched, as long as the underlying implementation > makes certain that any iteration of the RelationshipTypes forms a set (no > duplicates). > > > There is no need to have RelationshipTypes in any particular order, and > if that is needed in the application, they can usually be sorted locally > since Nodes will generally have associated Relationships of only a handful > of RelationshipTypes. > > > > > > That said, the more important question is, if the Neo4j store can > produce this meta-information. For sparsely connected nodes, it is possible > to iterate over the relationships and return the set of RelationshipTypes, > but this is not a proper solution when nodes are densely connected. So there > is no general solution for this question yet. > > > Niels > > > > > >> From: j...@neotechnology.com > > >> Date: Sun, 31 Jul 2011 17:29:29 +0100 > > >> To: user@lists.neo4j.org > > >> Subject: Re: [Neo4j] Node#getRelationshipTypes > > >> > > >> Hi Niels, > > >> > > >> Ignoring the operational use for getting relationship types, I do > think these should be generalised from: > > >> > > >>> RelationshipType[] getRelationshipTypes(); > > >>> RelationshipType[] getRelationshipTypes(Direction); > > >> > > >> to: > > >> > > >> Set<RelationshipType> getRelationshipTypes(); > > >> Set<RelationshipType> getgetRelationshipTypes(Direction); > > >> > > >> Unless you need the ordering and you think the overhead of creating a > some kind of Set is too onerous from a performance point of view. > > >> > > >> Jim > > >> _______________________________________________ > > >> 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 > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
