Duane
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com t. @duanechaos
"Don't fear the Graph! Embrace Neo4J"
On Tuesday, July 24, 2012 6:01:10 PM UTC-4, roymond wrote:
> Are there any live demo sites to see what people are doing with Neo4j? I
> haven't found any and would love to see examples.
My company, Technoracle, has a product we are about to launch with Neo4J on
the back end. We plan to add full architecture docs to show the immense
business value of Neo4J. ETA < 3 months.
Duane Nickull
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com t. @duanechaos
"Don't fear the Graph! Embrace Neo4J"
I'm the co-founder of http://www.thethingdom.com/ , a social network around
products, and it uses Neo4j from Node.js. We in fact wrote and open-sourced
the Node.js-Neo4j driver. =)
du...@technoracle-systems.com> wrote:
> My company, Technoracle, has a product we are about to launch with Neo4J
> on the back end. We plan to add full architecture docs to show the immense
> business value of Neo4J. ETA < 3 months.
> Duane Nickull
> ***********************************
> Technoracle Advanced Systems Inc.
> Consulting and Contracting; Proven Results!
> i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
> b. http://technoracle.blogspot.com > t. @duanechaos
> "Don't fear the Graph! Embrace Neo4J"
For some reason I don't see my original comment anymore, but I'd love
to talk a bit more about my experiences.
Let's first start with the basics. Neo4j is a schemaless database,
something I greatly appreciate since it allowed me to create my own
schema on top of the graph store. In order to do that, I started by
wrapping the entire Neo4j API in Scala.
Having classes such as PropertyType and RelationhipType, made it
possible to move all graph traversal and manipulation towards those
types.
Where the Neo4j API has all graph manipulation methods on the Node, in
multispective.com all those methods have been moved towards
PropertyType and RelationshipType, making it possible to plug in
different implementations where needed. E.g. there is a
RelationshipListType, which places all relationships in an ordered
list (in-graph), but can be treated like an ordinary RelationshipType
in the API.
Another aspect of the schema is that every database element derives
from the same base class (Vertex). As a result, properties and
relationships can be treated as if they were Nodes, and both can have
properties and relationships themselves. This is achieved through the
use of shadow-nodes, where each property or relationship can have an
associated node, on which properties and relationships are stored.
This is done on a per-need basis, so only those properties that
require properties and/or relationships and relationships that require
relationships, have such a shadow node (a much nicer solution than
having to use a bipartite layout throughout the graph).
By giving every database element the same base class, access-control
becomes rather easy, since it can be handled in the base class.
Multitenency is achieved by modeling each user or user-group as a
separate domain. Each domain has its own associated namespace where
domain owners can define their own ContentTypes, PropertyTypes and
RelationshipTypes, while each domain can also import schema
definitions from other domains (if allowed by the owners of those
domains).
Within the various types, domain owners can model URL-paths, so each
domain can have it's own URL-structure if such is needed. Each URL-
path can have associated HTML templates, CSS code and Javascript code
that will be used to produce the required HTML output.
Example:
Suppose we have a blog entry stored at mydomain.com/blog/niels/
my_first_blog_entry.
Template resolution starts looking for templates/css/javascript
associated with that particular URL (which is represented in the
database as a Node). If no templates (also stored in the database as a
Node) are found at that level, the search will continue for the path:
mydomain.com/blog/niels/. Again if nothing is found, search with
continue for the path mydomain.com/blog/. Finally if nothing is found
up to the path mydomain.com, default template/css/javascript is used
----
Domain owners can add their own templates/css/javascript (at least the
ones that pay for their subscription, free-user accounts don't have
this option) and with that have complete control over the rendered
output.
Altogether the experience of building this on top of Neo4j has been a
positive experience. The choice for Scala as a programming language
too has helped a lot creating this beast, especially due to the superb
collection libraries and the use of higher-order functions.
At times, I have missed the option to have a proper key-value store,
although Lucene can be used for that purpose, but isn't as fast as a
dedicated key-value store.
Another observation is that thinking in traversals over a graph makes
a lot of sense for a Content Management System. After all, most of the
database retrievals are local to a given entity.
One drawback I have noticed so far, relative to an RDBMS, is that sort
order requires more advanced planning and isn't straigtforwardly
supported at the database level. Hopefully in some future release
(neo4j 2.0) the relationship store can be completely redesigned in
order to allow for fast access to specific relationships with a given
sort-order.
Niels
On Jul 27, 12:10 pm, Jim Webber <j...@neotechnology.com> wrote:
did you publish this already in this depth as a blog post? I remember one blog post from you about multiperspective, but that was a more high level post?
It would be great if this approach got out there so please publish this email content on the web
> For some reason I don't see my original comment anymore, but I'd love
> to talk a bit more about my experiences.
> Let's first start with the basics. Neo4j is a schemaless database,
> something I greatly appreciate since it allowed me to create my own
> schema on top of the graph store. In order to do that, I started by
> wrapping the entire Neo4j API in Scala.
> Having classes such as PropertyType and RelationhipType, made it
> possible to move all graph traversal and manipulation towards those
> types.
> Where the Neo4j API has all graph manipulation methods on the Node, in
> multispective.com all those methods have been moved towards
> PropertyType and RelationshipType, making it possible to plug in
> different implementations where needed. E.g. there is a
> RelationshipListType, which places all relationships in an ordered
> list (in-graph), but can be treated like an ordinary RelationshipType
> in the API.
> Another aspect of the schema is that every database element derives
> from the same base class (Vertex). As a result, properties and
> relationships can be treated as if they were Nodes, and both can have
> properties and relationships themselves. This is achieved through the
> use of shadow-nodes, where each property or relationship can have an
> associated node, on which properties and relationships are stored.
> This is done on a per-need basis, so only those properties that
> require properties and/or relationships and relationships that require
> relationships, have such a shadow node (a much nicer solution than
> having to use a bipartite layout throughout the graph).
> By giving every database element the same base class, access-control
> becomes rather easy, since it can be handled in the base class.
> Multitenency is achieved by modeling each user or user-group as a
> separate domain. Each domain has its own associated namespace where
> domain owners can define their own ContentTypes, PropertyTypes and
> RelationshipTypes, while each domain can also import schema
> definitions from other domains (if allowed by the owners of those
> domains).
> Within the various types, domain owners can model URL-paths, so each
> domain can have it's own URL-structure if such is needed. Each URL-
> path can have associated HTML templates, CSS code and Javascript code
> that will be used to produce the required HTML output.
> Example:
> Suppose we have a blog entry stored at mydomain.com/blog/niels/
> my_first_blog_entry.
> Template resolution starts looking for templates/css/javascript
> associated with that particular URL (which is represented in the
> database as a Node). If no templates (also stored in the database as a
> Node) are found at that level, the search will continue for the path:
> mydomain.com/blog/niels/. Again if nothing is found, search with
> continue for the path mydomain.com/blog/. Finally if nothing is found
> up to the path mydomain.com, default template/css/javascript is used
> ----
> Domain owners can add their own templates/css/javascript (at least the
> ones that pay for their subscription, free-user accounts don't have
> this option) and with that have complete control over the rendered
> output.
> Altogether the experience of building this on top of Neo4j has been a
> positive experience. The choice for Scala as a programming language
> too has helped a lot creating this beast, especially due to the superb
> collection libraries and the use of higher-order functions.
> At times, I have missed the option to have a proper key-value store,
> although Lucene can be used for that purpose, but isn't as fast as a
> dedicated key-value store.
> Another observation is that thinking in traversals over a graph makes
> a lot of sense for a Content Management System. After all, most of the
> database retrievals are local to a given entity.
> One drawback I have noticed so far, relative to an RDBMS, is that sort
> order requires more advanced planning and isn't straigtforwardly
> supported at the database level. Hopefully in some future release
> (neo4j 2.0) the relationship store can be completely redesigned in
> order to allow for fast access to specific relationships with a given
> sort-order.
> Niels
> On Jul 27, 12:10 pm, Jim Webber <j...@neotechnology.com> wrote:
>> Hey Niels,
>> That's pretty sweet! Congratulations.
>> Would you share your experiences of designing for multitennancy here? I think it would be fascinating to learn what you know.
Well, there is also Sylva [1] (still in beta). It allows you to define
your own schema for your data and then, it creates for you all the
forms to fill and create the graph. It has options to export the graph
as .gexf, collaborative work with a team in a same graph, search
feature across all the properties of a node or relationship, and the
schema is flexible so you can edit as many times as you want :D
> did you publish this already in this depth as a blog post? I remember one blog post from you about multiperspective, but that was a more high level post?
> It would be great if this approach got out there so please publish this email content on the web
> Thanks a lot
> Michael
> Am 27.07.2012 um 15:37 schrieb Niels Hoogeveen:
>> Hi Jim,
>> For some reason I don't see my original comment anymore, but I'd love
>> to talk a bit more about my experiences.
>> Let's first start with the basics. Neo4j is a schemaless database,
>> something I greatly appreciate since it allowed me to create my own
>> schema on top of the graph store. In order to do that, I started by
>> wrapping the entire Neo4j API in Scala.
>> Having classes such as PropertyType and RelationhipType, made it
>> possible to move all graph traversal and manipulation towards those
>> types.
>> Where the Neo4j API has all graph manipulation methods on the Node, in
>> multispective.com all those methods have been moved towards
>> PropertyType and RelationshipType, making it possible to plug in
>> different implementations where needed. E.g. there is a
>> RelationshipListType, which places all relationships in an ordered
>> list (in-graph), but can be treated like an ordinary RelationshipType
>> in the API.
>> Another aspect of the schema is that every database element derives
>> from the same base class (Vertex). As a result, properties and
>> relationships can be treated as if they were Nodes, and both can have
>> properties and relationships themselves. This is achieved through the
>> use of shadow-nodes, where each property or relationship can have an
>> associated node, on which properties and relationships are stored.
>> This is done on a per-need basis, so only those properties that
>> require properties and/or relationships and relationships that require
>> relationships, have such a shadow node (a much nicer solution than
>> having to use a bipartite layout throughout the graph).
>> By giving every database element the same base class, access-control
>> becomes rather easy, since it can be handled in the base class.
>> Multitenency is achieved by modeling each user or user-group as a
>> separate domain. Each domain has its own associated namespace where
>> domain owners can define their own ContentTypes, PropertyTypes and
>> RelationshipTypes, while each domain can also import schema
>> definitions from other domains (if allowed by the owners of those
>> domains).
>> Within the various types, domain owners can model URL-paths, so each
>> domain can have it's own URL-structure if such is needed. Each URL-
>> path can have associated HTML templates, CSS code and Javascript code
>> that will be used to produce the required HTML output.
>> Example:
>> Suppose we have a blog entry stored at mydomain.com/blog/niels/
>> my_first_blog_entry.
>> Template resolution starts looking for templates/css/javascript
>> associated with that particular URL (which is represented in the
>> database as a Node). If no templates (also stored in the database as a
>> Node) are found at that level, the search will continue for the path:
>> mydomain.com/blog/niels/. Again if nothing is found, search with
>> continue for the path mydomain.com/blog/. Finally if nothing is found
>> up to the path mydomain.com, default template/css/javascript is used
>> ----
>> Domain owners can add their own templates/css/javascript (at least the
>> ones that pay for their subscription, free-user accounts don't have
>> this option) and with that have complete control over the rendered
>> output.
>> Altogether the experience of building this on top of Neo4j has been a
>> positive experience. The choice for Scala as a programming language
>> too has helped a lot creating this beast, especially due to the superb
>> collection libraries and the use of higher-order functions.
>> At times, I have missed the option to have a proper key-value store,
>> although Lucene can be used for that purpose, but isn't as fast as a
>> dedicated key-value store.
>> Another observation is that thinking in traversals over a graph makes
>> a lot of sense for a Content Management System. After all, most of the
>> database retrievals are local to a given entity.
>> One drawback I have noticed so far, relative to an RDBMS, is that sort
>> order requires more advanced planning and isn't straigtforwardly
>> supported at the database level. Hopefully in some future release
>> (neo4j 2.0) the relationship store can be completely redesigned in
>> order to allow for fast access to specific relationships with a given
>> sort-order.
>> Niels
>> On Jul 27, 12:10 pm, Jim Webber <j...@neotechnology.com> wrote:
>>> Hey Niels,
>>> That's pretty sweet! Congratulations.
>>> Would you share your experiences of designing for multitennancy here? I think it would be fascinating to learn what you know.
On Saturday, July 28, 2012 11:12:50 PM UTC+2, Michael Hunger wrote: > Niels,
> did you publish this already in this depth as a blog post? I remember one > blog post from you about multiperspective, but that was a more high level > post?
> It would be great if this approach got out there so please publish this > email content on the web
> Thanks a lot
> Michael
> Am 27.07.2012 um 15:37 schrieb Niels Hoogeveen:
> > Hi Jim,
> > For some reason I don't see my original comment anymore, but I'd love > > to talk a bit more about my experiences.
> > Let's first start with the basics. Neo4j is a schemaless database, > > something I greatly appreciate since it allowed me to create my own > > schema on top of the graph store. In order to do that, I started by > > wrapping the entire Neo4j API in Scala.
> > Having classes such as PropertyType and RelationhipType, made it > > possible to move all graph traversal and manipulation towards those > > types.
> > Where the Neo4j API has all graph manipulation methods on the Node, in > > multispective.com all those methods have been moved towards > > PropertyType and RelationshipType, making it possible to plug in > > different implementations where needed. E.g. there is a > > RelationshipListType, which places all relationships in an ordered > > list (in-graph), but can be treated like an ordinary RelationshipType > > in the API.
> > Another aspect of the schema is that every database element derives > > from the same base class (Vertex). As a result, properties and > > relationships can be treated as if they were Nodes, and both can have > > properties and relationships themselves. This is achieved through the > > use of shadow-nodes, where each property or relationship can have an > > associated node, on which properties and relationships are stored. > > This is done on a per-need basis, so only those properties that > > require properties and/or relationships and relationships that require > > relationships, have such a shadow node (a much nicer solution than > > having to use a bipartite layout throughout the graph).
> > By giving every database element the same base class, access-control > > becomes rather easy, since it can be handled in the base class.
> > Multitenency is achieved by modeling each user or user-group as a > > separate domain. Each domain has its own associated namespace where > > domain owners can define their own ContentTypes, PropertyTypes and > > RelationshipTypes, while each domain can also import schema > > definitions from other domains (if allowed by the owners of those > > domains).
> > Within the various types, domain owners can model URL-paths, so each > > domain can have it's own URL-structure if such is needed. Each URL- > > path can have associated HTML templates, CSS code and Javascript code > > that will be used to produce the required HTML output.
> > Example:
> > Suppose we have a blog entry stored at mydomain.com/blog/niels/ > > my_first_blog_entry.
> > Template resolution starts looking for templates/css/javascript > > associated with that particular URL (which is represented in the > > database as a Node). If no templates (also stored in the database as a > > Node) are found at that level, the search will continue for the path: > > mydomain.com/blog/niels/. Again if nothing is found, search with > > continue for the path mydomain.com/blog/. Finally if nothing is found > > up to the path mydomain.com, default template/css/javascript is used > > ----
> > Domain owners can add their own templates/css/javascript (at least the > > ones that pay for their subscription, free-user accounts don't have > > this option) and with that have complete control over the rendered > > output.
> > Altogether the experience of building this on top of Neo4j has been a > > positive experience. The choice for Scala as a programming language > > too has helped a lot creating this beast, especially due to the superb > > collection libraries and the use of higher-order functions.
> > At times, I have missed the option to have a proper key-value store, > > although Lucene can be used for that purpose, but isn't as fast as a > > dedicated key-value store.
> > Another observation is that thinking in traversals over a graph makes > > a lot of sense for a Content Management System. After all, most of the > > database retrievals are local to a given entity.
> > One drawback I have noticed so far, relative to an RDBMS, is that sort > > order requires more advanced planning and isn't straigtforwardly > > supported at the database level. Hopefully in some future release > > (neo4j 2.0) the relationship store can be completely redesigned in > > order to allow for fast access to specific relationships with a given > > sort-order.
> > Niels
> > On Jul 27, 12:10 pm, Jim Webber <j...@neotechnology.com> wrote: > >> Hey Niels,
> >> That's pretty sweet! Congratulations.
> >> Would you share your experiences of designing for multitennancy here? I > think it would be fascinating to learn what you know.
On Sunday, July 29, 2012 5:07:18 PM UTC+2, Niels Hoogeveen wrote: > Hi Michael,
> I will do my best to put out a blog post on multispective containing the > information I put out in this thread.
> Niels > On Saturday, July 28, 2012 11:12:50 PM UTC+2, Michael Hunger wrote:
>> Niels,
>> did you publish this already in this depth as a blog post? I remember one >> blog post from you about multiperspective, but that was a more high level >> post?
>> It would be great if this approach got out there so please publish this >> email content on the web
>> Thanks a lot
>> Michael
>> Am 27.07.2012 um 15:37 schrieb Niels Hoogeveen:
>> > Hi Jim,
>> > For some reason I don't see my original comment anymore, but I'd love >> > to talk a bit more about my experiences.
>> > Let's first start with the basics. Neo4j is a schemaless database, >> > something I greatly appreciate since it allowed me to create my own >> > schema on top of the graph store. In order to do that, I started by >> > wrapping the entire Neo4j API in Scala.
>> > Having classes such as PropertyType and RelationhipType, made it >> > possible to move all graph traversal and manipulation towards those >> > types.
>> > Where the Neo4j API has all graph manipulation methods on the Node, in >> > multispective.com all those methods have been moved towards >> > PropertyType and RelationshipType, making it possible to plug in >> > different implementations where needed. E.g. there is a >> > RelationshipListType, which places all relationships in an ordered >> > list (in-graph), but can be treated like an ordinary RelationshipType >> > in the API.
>> > Another aspect of the schema is that every database element derives >> > from the same base class (Vertex). As a result, properties and >> > relationships can be treated as if they were Nodes, and both can have >> > properties and relationships themselves. This is achieved through the >> > use of shadow-nodes, where each property or relationship can have an >> > associated node, on which properties and relationships are stored. >> > This is done on a per-need basis, so only those properties that >> > require properties and/or relationships and relationships that require >> > relationships, have such a shadow node (a much nicer solution than >> > having to use a bipartite layout throughout the graph).
>> > By giving every database element the same base class, access-control >> > becomes rather easy, since it can be handled in the base class.
>> > Multitenency is achieved by modeling each user or user-group as a >> > separate domain. Each domain has its own associated namespace where >> > domain owners can define their own ContentTypes, PropertyTypes and >> > RelationshipTypes, while each domain can also import schema >> > definitions from other domains (if allowed by the owners of those >> > domains).
>> > Within the various types, domain owners can model URL-paths, so each >> > domain can have it's own URL-structure if such is needed. Each URL- >> > path can have associated HTML templates, CSS code and Javascript code >> > that will be used to produce the required HTML output.
>> > Example:
>> > Suppose we have a blog entry stored at mydomain.com/blog/niels/ >> > my_first_blog_entry.
>> > Template resolution starts looking for templates/css/javascript >> > associated with that particular URL (which is represented in the >> > database as a Node). If no templates (also stored in the database as a >> > Node) are found at that level, the search will continue for the path: >> > mydomain.com/blog/niels/. Again if nothing is found, search with >> > continue for the path mydomain.com/blog/. Finally if nothing is found >> > up to the path mydomain.com, default template/css/javascript is used >> > ----
>> > Domain owners can add their own templates/css/javascript (at least the >> > ones that pay for their subscription, free-user accounts don't have >> > this option) and with that have complete control over the rendered >> > output.
>> > Altogether the experience of building this on top of Neo4j has been a >> > positive experience. The choice for Scala as a programming language >> > too has helped a lot creating this beast, especially due to the superb >> > collection libraries and the use of higher-order functions.
>> > At times, I have missed the option to have a proper key-value store, >> > although Lucene can be used for that purpose, but isn't as fast as a >> > dedicated key-value store.
>> > Another observation is that thinking in traversals over a graph makes >> > a lot of sense for a Content Management System. After all, most of the >> > database retrievals are local to a given entity.
>> > One drawback I have noticed so far, relative to an RDBMS, is that sort >> > order requires more advanced planning and isn't straigtforwardly >> > supported at the database level. Hopefully in some future release >> > (neo4j 2.0) the relationship store can be completely redesigned in >> > order to allow for fast access to specific relationships with a given >> > sort-order.
>> > Niels
>> > On Jul 27, 12:10 pm, Jim Webber <j...@neotechnology.com> wrote: >> >> Hey Niels,
>> >> That's pretty sweet! Congratulations.
>> >> Would you share your experiences of designing for multitennancy here? >> I think it would be fascinating to learn what you know.
> The post doesn't describe things at the level of Neo4j since I want this post to be geared to the more casual reader.
> Niels
> On Sunday, July 29, 2012 5:07:18 PM UTC+2, Niels Hoogeveen wrote:
> Hi Michael,
> I will do my best to put out a blog post on multispective containing the information I put out in this thread.
> Niels
> On Saturday, July 28, 2012 11:12:50 PM UTC+2, Michael Hunger wrote:
> Niels,
> did you publish this already in this depth as a blog post? I remember one blog post from you about multiperspective, but that was a more high level post?
> It would be great if this approach got out there so please publish this email content on the web
> Thanks a lot
> Michael
> Am 27.07.2012 um 15:37 schrieb Niels Hoogeveen:
> > Hi Jim,
> > For some reason I don't see my original comment anymore, but I'd love > > to talk a bit more about my experiences.
> > Let's first start with the basics. Neo4j is a schemaless database, > > something I greatly appreciate since it allowed me to create my own > > schema on top of the graph store. In order to do that, I started by > > wrapping the entire Neo4j API in Scala.
> > Having classes such as PropertyType and RelationhipType, made it > > possible to move all graph traversal and manipulation towards those > > types.
> > Where the Neo4j API has all graph manipulation methods on the Node, in > > multispective.com all those methods have been moved towards > > PropertyType and RelationshipType, making it possible to plug in > > different implementations where needed. E.g. there is a > > RelationshipListType, which places all relationships in an ordered > > list (in-graph), but can be treated like an ordinary RelationshipType > > in the API.
> > Another aspect of the schema is that every database element derives > > from the same base class (Vertex). As a result, properties and > > relationships can be treated as if they were Nodes, and both can have > > properties and relationships themselves. This is achieved through the > > use of shadow-nodes, where each property or relationship can have an > > associated node, on which properties and relationships are stored. > > This is done on a per-need basis, so only those properties that > > require properties and/or relationships and relationships that require > > relationships, have such a shadow node (a much nicer solution than > > having to use a bipartite layout throughout the graph).
> > By giving every database element the same base class, access-control > > becomes rather easy, since it can be handled in the base class.
> > Multitenency is achieved by modeling each user or user-group as a > > separate domain. Each domain has its own associated namespace where > > domain owners can define their own ContentTypes, PropertyTypes and > > RelationshipTypes, while each domain can also import schema > > definitions from other domains (if allowed by the owners of those > > domains).
> > Within the various types, domain owners can model URL-paths, so each > > domain can have it's own URL-structure if such is needed. Each URL- > > path can have associated HTML templates, CSS code and Javascript code > > that will be used to produce the required HTML output.
> > Example:
> > Suppose we have a blog entry stored at mydomain.com/blog/niels/ > > my_first_blog_entry.
> > Template resolution starts looking for templates/css/javascript > > associated with that particular URL (which is represented in the > > database as a Node). If no templates (also stored in the database as a > > Node) are found at that level, the search will continue for the path: > > mydomain.com/blog/niels/. Again if nothing is found, search with > > continue for the path mydomain.com/blog/. Finally if nothing is found > > up to the path mydomain.com, default template/css/javascript is used > > ----
> > Domain owners can add their own templates/css/javascript (at least the > > ones that pay for their subscription, free-user accounts don't have > > this option) and with that have complete control over the rendered > > output.
> > Altogether the experience of building this on top of Neo4j has been a > > positive experience. The choice for Scala as a programming language > > too has helped a lot creating this beast, especially due to the superb > > collection libraries and the use of higher-order functions.
> > At times, I have missed the option to have a proper key-value store, > > although Lucene can be used for that purpose, but isn't as fast as a > > dedicated key-value store.
> > Another observation is that thinking in traversals over a graph makes > > a lot of sense for a Content Management System. After all, most of the > > database retrievals are local to a given entity.
> > One drawback I have noticed so far, relative to an RDBMS, is that sort > > order requires more advanced planning and isn't straigtforwardly > > supported at the database level. Hopefully in some future release > > (neo4j 2.0) the relationship store can be completely redesigned in > > order to allow for fast access to specific relationships with a given > > sort-order.
> > Niels
> > On Jul 27, 12:10 pm, Jim Webber <j...@neotechnology.com> wrote: > >> Hey Niels,
> >> That's pretty sweet! Congratulations.
> >> Would you share your experiences of designing for multitennancy here? I think it would be fascinating to learn what you know.
