[
https://issues.apache.org/jira/browse/TINKERPOP3-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP3-846.
-----------------------------------------
Resolution: Won't Fix
Won't fix. We don't want providers who have "real graph databases" that don't
provide OLAP to have their users get {{OutOfMemoryExceptions}} -- that is not
fair to them as it makes it look like their system is "bad." We can always doc
it up that "this is not a 'real' OLAP engine...blah blah" but this will just
cause more confusions/problems. Best to require the provider to provide an OLAP
implementation they are comfortable with for their system.
However, note that {{TinkerGraphComputer}} is basically this request and if a
provider WANTS to provide an in-memory/threaded OLAP to their system, they can
simply copy/paste the code from TinkerGraph. It is really trivial to do.
> General In-Memory GraphComputer
> -------------------------------
>
> Key: TINKERPOP3-846
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-846
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.2-incubating
> Reporter: Matthias Broecheler
> Assignee: Marko A. Rodriguez
>
> Implement a generalized In-Memory GraphComputer that can be utilized by any
> vendor for use cases of small graphs and where performance isn't critical.
> This GraphComputer would, similar to the one for TinkerGraph, keep everything
> in memory. It would rely on the {{graph.vertices()}} method of the underlying
> graph for access to the data.
> Note, this looks likes a duplicate of TINKERPOP3-42. However, the motivation
> for this ticket is not to develop an efficient GraphComputer or one that can
> deal with large graphs - just a default implementation. Also, it is not clear
> why the view would need to copy the entire graph or cache. The view would
> only need to hold the delta that is being modified by the GraphComputer.
> This would be incredibly useful as a utility for vendors to use for small
> scale graphs where hassle of setting up Hadoop or Spark is just too much.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
