I should further say after looking more at Spring Data Neo4j ... that it allows an easy Type system layer on top of Neo4j. Is that correct ? The same kind of Type system that Freebase.com has had always.
In fact, Micheal, I would say even say that with Spring Data Neo4j installed, you could almost point users to the Freebase Data modeling style guide as a good reference : http://wiki.freebase.com/wiki/Data_modeling_style_guide On Fri, Oct 14, 2011 at 11:26 AM, Thad Guidry <[email protected]> wrote: > From your quick example, it looks like Spring Data Neo4j is what most folks > really expect out of the box with Neo4j. I know I certainly did when I > installed Neo4j for the first time, last year. Spring Data seems to meet > with my expectation (based on my bottom-up Schema-evolving work on > Freebase.com) > > > On Fri, Oct 14, 2011 at 11:15 AM, Michael Hunger < > [email protected]> wrote: > >> With spring data neo4j you are able to use any domain entity with any >> node, so it is for instance >> possible to project an entity to another when used in a different context. >> >> Otherwise the Spring Data Neo4j config less invasive and more concise than >> the existing model >> but uses the same approach behind the scenes (fields are mapped to >> properties and relationships - 1:1 or 1:n are mapped to relationships). >> >> @NodeEntity >> class Movie { >> String title; >> Set<Actor> actors; >> } >> >> a more elaborate example. >> @NodeEntity >> class Movie { >> @GraphId Long id; >> @Indexed(fulltext=true, indexName="movies") String title; >> @RelatedToVia(type="ACTS_IN", direction=Direction.INCOMING) >> Iterable<Role> roles; >> Person director; >> } >> >> @RelationshipEntity >> class Role { >> @Indexed String title; >> @StartNode Actor actor; >> @EndNode Movie movie; >> } >> >> @NodeEntity >> class Actor { >> String name; >> Gender gender; >> Date birthday; >> public Role actsIn(Movie movie, String role) { >> return relateTo(movie,"ACTS_IN",Role.class).withTitle(role); >> } >> @RelatedTo(type="ACTS_IN") >> Set<Movie> movies; >> } >> >> >> Am 14.10.2011 um 16:14 schrieb Thad Guidry: >> >> > I would suggest breaking down his statement further and fill in the >> blanks >> > to gain even better insight into his conjecture. >> > >> > "it‘s basically a bunch of nodes where you just blob your attributes.‘ >> > Worse than that, to wrap objects around it, you have to have them >> explicitly >> > incorporate their node class, which is ugly, smelly, violates every law >> of >> > separation of concerns and logical vs. physical models." >> > >> > >> > "it's" - Neo4j >> > >> > "to wrap objects around IT" - what is the IT that he is referring to ? >> > >> > "you have to have THEM explicitly incorporate THEIR node class" - what >> is >> > THEM / THEIR really mean for Neo4j here ? >> > >> > "law of separation of concerns" - what and where are we JOINING that >> should >> > be SEPARATING , is it only the Domain objects ? >> > >> > >> > From outside looking in, I have seen others not complete their Domain >> Model >> > as needed with Neo4j, and also make it entirely TOO SIMPLE. Why ? >> Because >> > they might be new to graph databases, or their Domain Model really IS >> NOT >> > complete yet and they need help from others to assist with putting >> together >> > an elegant Domain Model to begin with. Being able to easily wire up a >> > Domain Model is the primary reason they were attracted to graph >> databases in >> > the first place !... to build it out without resorting to defining a >> rigid >> > schema (a SQL table mantra). But many need help in contorting their >> Domain >> > Model over time. To me, Neo4j is already wide open enough to handle >> that >> > contortion and the beauty of Neo4j & graph databases in general. >> > >> > Folks just need better much more detailed Domain Model examples than >> what is >> > available, that would help incredibly so, since many folks have a >> complex >> > Domain Model to begin with (they just do not realize it yet) and they >> are >> > hoping Neo4j will help them quickly wire it up, stretch it out when >> needed, >> > and analyze the hell out of it when the time comes, and stretch it out >> even >> > more as they continue to fill it up and expand their Domain Model. A >> bottom >> > up approach (and I mean really BOTTOM) is the best practice, but it does >> > take thought and research in finding where that generic bottom is at. A >> > "Friend" - what is a Friend, what attributes does a Friend have ? Which >> ones >> > do I care about now and can worry about later ? A "Stock Issuing >> Company", >> > do I need to think of my relationships first for those, or should I >> start >> > with attributes ? Will those attributes be shared with others ? Do I >> care >> > about it now at this early beginning of my Domain Model, or can I wait >> on >> > this ? Should I start with attributes (properties) always, and leave >> > relationships alone until the very end, when I build a Domain Model ? >> (the >> > answer to that last question is YES, because Neo4j actually DOES allow >> you >> > to) >> > >> >> He attacks our pattern of building domain models with Neo4j, calling it >> >>> "ugly", "smelly" and "in violation of every law of separation of >> concerns >> >>> and logical vs. physical models". Is he right? My feeling is that he >> is >> >>> brain washed with too many so called "best practices", but Neo4j has >> been >> >> my >> >>> main model for a long time now, my perspective is likely skewed. I'd >> like >> >> to >> >>> hear your thoughts. >> >> >> > >> > Your main model IS NOT Neo4j. That is your main database that "holds" >> your >> > Domain Model. And if Neo4j is not really doing this from top to bottom, >> > then I would agree with Richard that the Neo4j infrastructure is not in >> the >> > best place right now and might need more work. >> > >> > -- >> > -Thad >> > http://www.freebase.com/view/en/thad_guidry >> > _______________________________________________ >> > Neo4j mailing list >> > [email protected] >> > https://lists.neo4j.org/mailman/listinfo/user >> >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user >> > > > > -- > -Thad > http://www.freebase.com/view/en/thad_guidry > -- -Thad http://www.freebase.com/view/en/thad_guidry _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
