Hi,

I also do not like having the producers ids in the relationship. This is
like having an non-indexed foreign key. I think the right solution is to
change the database structure to match the intention of the model.

I'll go out on a limb here and make some assumptions about what you really
mean by your model. You want to ask 'who consumes assets by this producer'.
Your problem is that what you are calling an Asset is actually a type of
Asset, but some consumers are interested in a specific asset, not just all
assets of that type, and so you are having to add extra data to resolve the
type in the 'subscribes' relationship. A far better solution is to have a
real asset node. By that I mean a 'ford mustan '68' node instead of a 'car'
node.

Then the case where the subscribes node has no producers property really
means the Consumer subscribers to the AssetType, and the case where there
are producers properties, the Consumer subscribers to those specific Assets
(where Asset is now specific to a producer).

Then the model will have no foreign keys, only relationships, and a plain
old standard out-the-box traverser will give you your answer :-)

Some further clarifications of the relationships I see in the graph:

   - Assets can have IS_A relationships to AssetTypes
   - Produces CONTRIBUTE_TO Assets, never AssetTypes (just like Ford
   produces the 'Ford Mustang', not 'cars')
   - Consumers can SUBSCRIBE_TO either Assets directly (ie. specific
   models), or AssetTypes (this deals with your two cases before, but no longer
   needs ids in properties)

The traverser can traverse directly from the Producer to the Subscriber
without any complications. Just follow the right relationships in the right
order, and only return Subscribers.

The paths could look like:

Producer1 --(contributes_to)--> AssetX <--(subscribes_to)-- Consumer1
                                   |
                                 (IS_A)
                                   |
                                   V
                            AssetTypeP <--(subscribes_to)-- Consumer2

Notice that traversing to consumers that are subscribing to specific assets
(assets by specific producers) is a shorter path than traversing to
consumers that subscribe to assets by any producer (asset types). This
should have no impact on the traverser. Just remember to include the IS_A
relationships type (with the right direction) to get the results you want.

Cheers, Craig

On Thu, Nov 25, 2010 at 12:00 AM, Mattias Persson <matt...@neotechnology.com
> wrote:

> Hi Kalin,
>
> To begin with I'm not fond of storing ids as properties... that's what
> relationships are for. So I'd perhaps insert a "middle node" between Asset
> and Consumer which then also can have relationships to Producers.
>
> Anyways, to get that behaviour you can use a filter which will exclude
> unwanted paths.
>
> Traversal.description().uniqueness(RELATIONSHIP_PATH)
>   .relationships(Contributes_to, OUTGOING)
>   .relationships(Subscribes_to, INCOMING)
>   .filter(new Predicate<Path>() {
>       public boolean accept(Path position) {
>           if ( position.length() != 2 ) return false;
>           Relationship subscribesToRel = position.lastRelationship();
>           if ( /* check properties on subscribesToRel is OK */ ) return
> true;
>           return false;
>       }
>   });
>
> do you need the pruneAfterDepth(2) here? I don't think so because I don't
> think your traverser will be able to go deeper anyways, but that's just a
> detail.
>
> 2010/11/24 Kalin Wilson <d...@kalinwilson.com>
>
> >   Im enjoying Neo4J so far. The new Traversal framework has a lot of
> >   potential. However, Id like to propose an extension to the
> >   RelationshipExpander interface or have someone tell me of another way
> >   to accomplish a task.
> >
> >
> >   Here is an outline of the basics of my network:
> >
> >
> >   Producer  contributes_to => Asset <= subscribes_to Consumer (various
> >   properties on each type of Node and Relationship)
> >
> >
> >   A Consumer may subscribe to an Asset generically or the subscribes_to
> >   relationship may have a property, producers, which is an array of ids
> >   (long) of Producer nodes that specifically produce assets for that
> >   Consumer.
> >
> >
> >   Given a list of Producer nodes, I want to retrieve all paths from a
> >   Producer to all of its Consumers through Assets. When at an Asset node
> >   the subscribes_to relationship should only be traversed if the
> >   relationship has no producers property (meaning the related Consumer
> >   consumes from all producers of that asset) or if the producers property
> >   contains the id of the Producer that we started with.
> >
> >
> >   My first approach was to implement RelationshipExpander to determine
> >   which relationships from Asset to traverse. However, since all the
> >   Expand() method has to work with is the current Node, I dont have
> >   enough information to make the decision above. I would need the current
> >   Path in order to know what Producer related to the current Asset the
> >   Traversal came from.
> >
> >
> >   Right now Im using this description which will give me
> >   Producer->Asset->Consumer paths but wont exclude based on producers on
> >   subscribes_to:
> >
> >
> >   TraversalDescription producerToConsumer = Traversal.description()
> >
> >   .depthFirst().uniqueness(Uniqueness.RELATIONSHIP_PATH)
> >
> >   .relationships(RelTypes.Contributes_to, Direction.OUTGOING)
> >
> >   .relationships(RelTypes.Subscribes_to,Direction.BOTH)
> >
> >   .prune(Traversal.pruneAfterDepth(2));
> >
> >
> >
> >   If there is a way to accomplish what I describe above with the current
> >   framework, Im open to suggestions, including a different network design
> >   to track the Producer to Consumer relationship as it relates to Asset.
> >
> >
> >   Alternatively, I suggest that there may be situations where the Path
> >   context is needed to make the decision on what relationships to
> >   traverse from a Node, hence perhaps add Expand(Path p) to the
> >   RelationshipExpander interface.
> >
> >
> >   Thanks,
> >
> >   Kalin
> >   --
> >    Kalin Wilson
> >   http://www.kalinwilson.com
> >   ________________________________________________
> >   Message sent using UebiMiau 2.7.9
> > _______________________________________________
> > 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
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to