Re: [Neo] Modelling advice
Isn't that the general approach when adding information to relationships? It's common in ER to introduce mapping tables that not only contain the foreign key references but also data as well. In OO its the same. Fortunately most of the time the newly introduced relationship type will evolve quickly into a important member of the business domain with even more relevant data and behaviour. Michael Qualified Relationships have also been introduced to qi4j. Emil Eifrem schrieb: > On Fri, Sep 26, 2008 at 12:37 AM, Jonny Wray <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I'm in the process of moving an application over from an RDF based graph >> store to Neo. So far it's being great but I'm currently hitting a modelling >> question that I'm sure some experience with the technology would help, and >> so I'm asking the group. > > Hi Jonny, > > I *think* I understand your problem and basically the solution will be > depending on the complexity of the evidence data. If it's fairly > complex, I think injecting a middle node will be the best way. So when > node1 is SIMILAR related (just making this up) to node2, then instead > of the obvious: > >( node1 ) -- SIMILAR --> ( node2 ) > > you would model it like this: > >( node1 ) -- SIMILAR --> ( node14 ) -- SIMILAR --> ( node2 ) > > Node 14 in this diagram is the middle node, and you an attach whatever > information you want to it, either in the form of properties or for > example separate evidence nodes that aggregate data for a single piece > of evidence and that attach to node14 through e.g. a > SUPPORTING_EVIDENCE relationship. > > But if your evidence data is simple enough, it may be enough to just > connect the nodes with a relationship and then add the data as > key-encoded properties. For example: > >( node1 ) -- SIMILAR --> ( node2 ) > > And then on the relationship, you would have properties like: > >evidence1.origin = something >evidence1.weight = 0.8f >evidence2.origin = somethingelse >evidence2.weight = 0.4f > > The advantage with the middle node design is that the node space > layout in a sense is more clean and flexible. But it loses out on > intuition and "white-board friendliness." > > The advantage with the second layout is that it's the intuitive and > obvious way to model this data. It also keeps the number of primitives > down. The disadvantage is that it's brittle to encode information in > the names of the property keys. (How do you delete one piece of > evidence? Gotta loop through all keys and do string matching. Yuk!) > > Which one is the better choice I believe comes down to personal > preference and the specifics of the actual domain. > > Does that make sense or did I misunderstand the use case? > > Cheers, > -- Michael Hunger Independent Consultant Web: http://www.jexp.de Email: [EMAIL PROTECTED] Enthusiastic Evangelist for Better Software Development Don't stop where you are: http://creating.passionate-developers.org We support Software Engineering Radio (www.se-radio.net) ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Modelling advice
On Fri, Sep 26, 2008 at 12:37 AM, Jonny Wray <[EMAIL PROTECTED]> wrote: > Hi, > > I'm in the process of moving an application over from an RDF based graph > store to Neo. So far it's being great but I'm currently hitting a modelling > question that I'm sure some experience with the technology would help, and > so I'm asking the group. Hi Jonny, I *think* I understand your problem and basically the solution will be depending on the complexity of the evidence data. If it's fairly complex, I think injecting a middle node will be the best way. So when node1 is SIMILAR related (just making this up) to node2, then instead of the obvious: ( node1 ) -- SIMILAR --> ( node2 ) you would model it like this: ( node1 ) -- SIMILAR --> ( node14 ) -- SIMILAR --> ( node2 ) Node 14 in this diagram is the middle node, and you an attach whatever information you want to it, either in the form of properties or for example separate evidence nodes that aggregate data for a single piece of evidence and that attach to node14 through e.g. a SUPPORTING_EVIDENCE relationship. But if your evidence data is simple enough, it may be enough to just connect the nodes with a relationship and then add the data as key-encoded properties. For example: ( node1 ) -- SIMILAR --> ( node2 ) And then on the relationship, you would have properties like: evidence1.origin = something evidence1.weight = 0.8f evidence2.origin = somethingelse evidence2.weight = 0.4f The advantage with the middle node design is that the node space layout in a sense is more clean and flexible. But it loses out on intuition and "white-board friendliness." The advantage with the second layout is that it's the intuitive and obvious way to model this data. It also keeps the number of primitives down. The disadvantage is that it's brittle to encode information in the names of the property keys. (How do you delete one piece of evidence? Gotta loop through all keys and do string matching. Yuk!) Which one is the better choice I believe comes down to personal preference and the specifics of the actual domain. Does that make sense or did I misunderstand the use case? Cheers, -- Emil Eifrém, CEO [EMAIL PROTECTED] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
[Neo] Modelling advice
Hi, I'm in the process of moving an application over from an RDF based graph store to Neo. So far it's being great but I'm currently hitting a modelling question that I'm sure some experience with the technology would help, and so I'm asking the group. The situation is that I have two related entities but that relationship is supported by some evidence, and I'd like to represent that evidence somehow and make it available for display, filtering, traversal decisions etc. A single relationship between two nodes can be supported by multiple pieces of evidence, and each piece of evidence can have multiple properties (eg publisher, type, probability, etc). So, my basic question is how would this sort of situation be modelled using Neo? Now, I could model this using edge properties by storing evidence types and instance identifiers as well as property names in the edge property keys, but I'm wondering if this is the best approach, or is maybe a combination of another data store (eg an embedded object store with evidence objects available via the source and target nodes) a better approach? Any thoughts or relevent experiences are welcome, thanks Jonny ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Holding nodes between transactions
On Thu, Sep 25, 2008 at 8:06 AM, Michael Hunger <[EMAIL PROTECTED]> wrote:
> Thanks for the answers. The main question however remains. I don't know how
> this is with Software Transactional Memory.
>
> If you hold nodes between transactions and they are e.g. deleted by another
> thread/user then your reference is no longer
> valid. Changed properties/relationships shouldn't matter as they are just
> provided by a transactional neo service. But
> removal is still a problem (imho).
If the node you wrap is deleted "from under you" (for example by
another operation) then you're going to get a runtime exception next
time you invoke a method on that node reference. So it's up to the
layer above to make sure that it invalidates any long-held references
to those nodes. There's nothing we can do to prevent that other than
alerting the client through a runtime exception.
In our applications, we new up domain wrappers very liberally. The
typical "getXXXByYYY()" operations on a service interface are for
example implemented as such:
// pseudo code
Person getPersonByName( String name )
{
Node underlyingNode = someIndex.getSingleNodeFor( name );
return new PersonImpl( underlyingNode );
}
And we also make sure that we in data structures in the upper layers
only store identifyers and execute a lookup, rather than references to
the actual nodes or relationships.
Does that help?
Cheers,
--
Emil Eifrém, CEO [EMAIL PROTECTED]
Neo Technology, www.neotechnology.com
Cell: +46 733 462 271 | US: 206 403 8808
___
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
