[jira] [Created] (TINKERPOP-2002) Create a blog post explaining the value of using TinkerPop
Jeremy Hanna created TINKERPOP-2002: --- Summary: Create a blog post explaining the value of using TinkerPop Key: TINKERPOP-2002 URL: https://issues.apache.org/jira/browse/TINKERPOP-2002 Project: TinkerPop Issue Type: Wish Components: documentation Reporter: Jeremy Hanna There are a lot of great references and recipes in the TinkerPop docs. One thing that would be nice to have is a simple explanation of what it means to use a TinkerPop implementation and what that guarantees. People coming from a relational world may misunderstand what to expect and might think they can do the equivalent of plugging in a new JDBC driver and away they go. Some things to include * How traversals are implementation agnostic with some caveats ** data types ** indexes * Connection options - different implementations may allow you to use TinkerPop drivers but may have implementation specific drivers for things like security or cluster awareness * How to migrate easily between TinkerPop implementations should the need arise -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1246) 'help' in the gremlin console should give the user something
[ https://issues.apache.org/jira/browse/TINKERPOP-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423073#comment-16423073 ] Jeremy Hanna commented on TINKERPOP-1246: - I think what's been given is sufficient. Thanks Stephen! > 'help' in the gremlin console should give the user something > > > Key: TINKERPOP-1246 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1246 > Project: TinkerPop > Issue Type: Improvement > Components: console >Affects Versions: 3.1.1-incubating >Reporter: Jeremy Hanna >Priority: Major > > A new user to TinkerPop and/or Gremlin will probably flounder initially and > will likely try to type 'help' in the gremlin-console. Currently it just > gives an error that help is not mapped to a class and gives the option to > show a stack trace. > I know there is :help for the command mode, but that's going to confuse them > further I think because those are special commands and not what they're > looking for. > Piggy backing on something [~rustyrazorblade] mentioned, perhaps we could > have it give a general message but help gremlin or help tinkerpop could open > the docs. > In general though, I think it would be useful to have something defined for > help - perhaps a basic explanation with a couple of examples with the toy > graph while also referring to the tutorials section of the site. Then it > would also be handy to override the help with specific commands like for each > of the commands in the docs like traversal steps (though that may be a lot of > work to maintain) such as 'help count' or 'help barrier'. Specific keywords > could be used like was mentioned 'help gremlin' or 'help tinkerpop' or 'help > docs' could open the docs. > Maybe some of this is overkill but I think overriding 'help' in some form > would be helpful for new users. Also just trying to brainstorm what could be > done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1737) Validate and throw an exception when maxContentLength overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated TINKERPOP-1737:
Priority: Trivial (was: Major)
> Validate and throw an exception when maxContentLength overflows
> ---
>
> Key: TINKERPOP-1737
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1737
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Reporter: Jeremy Hanna
>Priority: Trivial
>
> If you set the {maxContentLength} to higher than {Integer.MAX_VALUE} it won't
> error out but the gremlin console is broken. We should probably do some sort
> of validation on startup and then fail fast with an appropriate error message
> instead.
> This can happen if people don't want to worry about the value and set it
> arbitrarily high and don't know that it's an integer.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TINKERPOP-1737) Validate and throw an exception when maxContentLength overflows
Jeremy Hanna created TINKERPOP-1737:
---
Summary: Validate and throw an exception when maxContentLength
overflows
Key: TINKERPOP-1737
URL: https://issues.apache.org/jira/browse/TINKERPOP-1737
Project: TinkerPop
Issue Type: Improvement
Components: server
Reporter: Jeremy Hanna
If you set the {maxContentLength} to higher than {Integer.MAX_VALUE} it won't
error out but the gremlin console is broken. We should probably do some sort
of validation on startup and then fail fast with an appropriate error message
instead.
This can happen if people don't want to worry about the value and set it
arbitrarily high and don't know that it's an integer.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1737) Validate and throw an exception when maxContentLength overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated TINKERPOP-1737:
Description:
If you set the {{maxContentLength}} to higher than {{Integer.MAX_VALUE}} it
won't error out but the gremlin console is broken. We should probably do some
sort of validation on startup and then fail fast with an appropriate error
message instead.
This can happen if people don't want to worry about the value and set it
arbitrarily high and don't know that it's an integer.
was:
If you set the {maxContentLength} to higher than {Integer.MAX_VALUE} it won't
error out but the gremlin console is broken. We should probably do some sort
of validation on startup and then fail fast with an appropriate error message
instead.
This can happen if people don't want to worry about the value and set it
arbitrarily high and don't know that it's an integer.
> Validate and throw an exception when maxContentLength overflows
> ---
>
> Key: TINKERPOP-1737
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1737
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Reporter: Jeremy Hanna
>Priority: Trivial
>
> If you set the {{maxContentLength}} to higher than {{Integer.MAX_VALUE}} it
> won't error out but the gremlin console is broken. We should probably do
> some sort of validation on startup and then fail fast with an appropriate
> error message instead.
> This can happen if people don't want to worry about the value and set it
> arbitrarily high and don't know that it's an integer.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1685) Introduce optional feature to allow for upserts without read-before-write
[
https://issues.apache.org/jira/browse/TINKERPOP-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated TINKERPOP-1685:
Description:
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on {{addV}} and {{addE}}. It could be called something like
{{upsert_on_add}}. This configuration would default to false so that it
doesn't break anyone currently relying on errors when adding the same vertex or
edge. However if enabled, it would just add or modify data on the existing
vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk. A benefit of a separate operator is
that you could mix upsert behavior and non-upsert add behavior in a single
graph. I'm not sure there is a huge need to use both in a single graph, but it
is a difference between the two strategies.
was:
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on {{addV}} and {{addE}}. This configuration would default
to false so that it doesn't break anyone currently relying on errors when
adding the same vertex or edge. However if enabled, it would just add or
modify data on the existing vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk. A benefit of a separate operator is
that you could mix upsert behavior and non-upsert add behavior in a single
graph. I'm not sure there is a huge need to use both in a single graph, but it
is a difference between the two strategies.
> Introduce optional feature to allow for upserts without read-before-write
> -
>
> Key: TINKERPOP-1685
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1685
> Project: TinkerPop
> Issue Type: Wish
>Reporter: Jeremy Hanna
>
> Currently TINKERPOP-479 is being considered to do some sort of
> {{getOrCreate}} functionality. However for some data stores such as
> Cassandra, this is still short of upserts. As I understand it,
> {{getOrCreate}} still has to do a read-before-write. In cases where the user
> can guarantee that upserts are going to be idempotent, there is a significant
> performance improvement and risk avoidance (race condition with
> multi-threaded read-before-write). Additionally with some data stores such
> as Apache Cassandra, the natural way to update data is with an upsert.
> This ticket is to consider adding an additional optional feature to support
> upserts by default on {{addV}} and {{addE}}. It could be called something
> like {{upsert_on_add}}. This configuration would default to false so that it
> doesn't break anyone currently relying on errors when adding the same vertex
> or edge. However if enabled, it would just add or modify data on the
> existing vertex or edge.
> If overriding the existing {{addV}} and {{addE}} operations with this
> optional feature is undesirable, then perhaps new operators could be added
>
[jira] [Updated] (TINKERPOP-1685) Introduce optional feature to allow for upserts without read-before-write
[
https://issues.apache.org/jira/browse/TINKERPOP-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated TINKERPOP-1685:
Description:
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on {{addV}} and {{addE}}. This configuration would default
to false so that it doesn't break anyone currently relying on errors when
adding the same vertex or edge. However if enabled, it would just add or
modify data on the existing vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk. A benefit of a separate operator is
that you could mix upsert behavior and non-upsert add behavior in a single
graph. I'm not sure there is a huge need to use both in a single graph, but it
is a difference between the two strategies.
was:
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on {{addV}} and {{addE}}. This configuration would default
to false so that it doesn't break anyone currently relying on errors when
adding the same vertex or edge. However if enabled, it would just add or
modify data on the existing vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk.
> Introduce optional feature to allow for upserts without read-before-write
> -
>
> Key: TINKERPOP-1685
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1685
> Project: TinkerPop
> Issue Type: Wish
>Reporter: Jeremy Hanna
>
> Currently TINKERPOP-479 is being considered to do some sort of
> {{getOrCreate}} functionality. However for some data stores such as
> Cassandra, this is still short of upserts. As I understand it,
> {{getOrCreate}} still has to do a read-before-write. In cases where the user
> can guarantee that upserts are going to be idempotent, there is a significant
> performance improvement and risk avoidance (race condition with
> multi-threaded read-before-write). Additionally with some data stores such
> as Apache Cassandra, the natural way to update data is with an upsert.
> This ticket is to consider adding an additional optional feature to support
> upserts by default on {{addV}} and {{addE}}. This configuration would
> default to false so that it doesn't break anyone currently relying on errors
> when adding the same vertex or edge. However if enabled, it would just add
> or modify data on the existing vertex or edge.
> If overriding the existing {{addV}} and {{addE}} operations with this
> optional feature is undesirable, then perhaps new operators could be added
> like {{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be
> used to both add and update the data. Allowing it to insert data is
> important because otherwise you are left with having to read-before-write
> which incurs the performance cost and race condition risk. A benefit of a
> separate operator is that you could mix upsert
[jira] [Created] (TINKERPOP-1685) Introduce optional feature to allow for upserts without read-before-write
Jeremy Hanna created TINKERPOP-1685:
---
Summary: Introduce optional feature to allow for upserts without
read-before-write
Key: TINKERPOP-1685
URL: https://issues.apache.org/jira/browse/TINKERPOP-1685
Project: TinkerPop
Issue Type: Wish
Reporter: Jeremy Hanna
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on add. This configuration would default to false so that
it doesn't break anyone currently relying on errors when adding the same vertex
or edge. However if enabled, it would just add or modify data on the existing
vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1685) Introduce optional feature to allow for upserts without read-before-write
[
https://issues.apache.org/jira/browse/TINKERPOP-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated TINKERPOP-1685:
Description:
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on {{addV}} and {{addE}}. This configuration would default
to false so that it doesn't break anyone currently relying on errors when
adding the same vertex or edge. However if enabled, it would just add or
modify data on the existing vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk.
was:
Currently TINKERPOP-479 is being considered to do some sort of {{getOrCreate}}
functionality. However for some data stores such as Cassandra, this is still
short of upserts. As I understand it, {{getOrCreate}} still has to do a
read-before-write. In cases where the user can guarantee that upserts are
going to be idempotent, there is a significant performance improvement and risk
avoidance (race condition with multi-threaded read-before-write). Additionally
with some data stores such as Apache Cassandra, the natural way to update data
is with an upsert.
This ticket is to consider adding an additional optional feature to support
upserts by default on add. This configuration would default to false so that
it doesn't break anyone currently relying on errors when adding the same vertex
or edge. However if enabled, it would just add or modify data on the existing
vertex or edge.
If overriding the existing {{addV}} and {{addE}} operations with this optional
feature is undesirable, then perhaps new operators could be added like
{{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be used to
both add and update the data. Allowing it to insert data is important because
otherwise you are left with having to read-before-write which incurs the
performance cost and race condition risk.
> Introduce optional feature to allow for upserts without read-before-write
> -
>
> Key: TINKERPOP-1685
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1685
> Project: TinkerPop
> Issue Type: Wish
>Reporter: Jeremy Hanna
>
> Currently TINKERPOP-479 is being considered to do some sort of
> {{getOrCreate}} functionality. However for some data stores such as
> Cassandra, this is still short of upserts. As I understand it,
> {{getOrCreate}} still has to do a read-before-write. In cases where the user
> can guarantee that upserts are going to be idempotent, there is a significant
> performance improvement and risk avoidance (race condition with
> multi-threaded read-before-write). Additionally with some data stores such
> as Apache Cassandra, the natural way to update data is with an upsert.
> This ticket is to consider adding an additional optional feature to support
> upserts by default on {{addV}} and {{addE}}. This configuration would
> default to false so that it doesn't break anyone currently relying on errors
> when adding the same vertex or edge. However if enabled, it would just add
> or modify data on the existing vertex or edge.
> If overriding the existing {{addV}} and {{addE}} operations with this
> optional feature is undesirable, then perhaps new operators could be added
> like {{upsertV}} and {{upsertE}} or {{putV}} and {{putE}} and those could be
> used to both add and update the data. Allowing it to insert data is
> important because otherwise you are left with having to read-before-write
> which incurs the performance cost and race condition risk.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1174) addVertex(Map properties) method
[
https://issues.apache.org/jira/browse/TINKERPOP-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905609#comment-15905609
]
Jeremy Hanna commented on TINKERPOP-1174:
-
This could also apply to the {{addEdge}} method with the varargs versus a map.
> addVertex(Map properties) method
>
>
> Key: TINKERPOP-1174
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1174
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.1-incubating
>Reporter: Matthias Broecheler
>Assignee: stephen mallette
>
> which overloads the other {{addVertex(Object... properties)}} method with a
> map based version (of key-value pairs).
> Having this alternative to addVertex is nice because:
> 1) It allows you to submit a map when adding vertices on remote graphs via
> drivers. Right now, you have to convert the properties to an array which is
> awkward and unnecessary
> 2) It would work well with groovy's map based syntax so one can write:
> {{g.addVertex( key1 : "value1", key2: "value2")}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1615) Doing a step many times can lead to unforeseen problems with the RepeatUnrollStrategy
[
https://issues.apache.org/jira/browse/TINKERPOP-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15892451#comment-15892451
]
Jeremy Hanna commented on TINKERPOP-1615:
-
I don't recall if I did but I'll give it a try.
> Doing a step many times can lead to unforeseen problems with the
> RepeatUnrollStrategy
> -
>
> Key: TINKERPOP-1615
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1615
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.3
>Reporter: Jeremy Hanna
>Assignee: Daniel Kuppitz
>
> The following traversal comes back with an error that appears to be related
> to the {{RepeatUnrollStrategy}}:
> {code}
> g.V().has('foo', 'id',
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> appears to either error out or take forever. However if I do something like:
> {code}
> g.withoutStrategies(RepeatUnrollStrategy.class).V().has('foo', 'id',
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> it works subsecond.
> So something funky with {{RepeatUnrollStrategy}} is going on.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TINKERPOP-1615) Doing a step many times can lead to unforeseen problems with the RepeatUnrollStrategy
Jeremy Hanna created TINKERPOP-1615:
---
Summary: Doing a step many times can lead to unforeseen problems
with the RepeatUnrollStrategy
Key: TINKERPOP-1615
URL: https://issues.apache.org/jira/browse/TINKERPOP-1615
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Jeremy Hanna
The following traversal comes back with an error that appears to be related to
the {{RepeatUnrollStrategy}}:
{code}
g.V().has('foo', 'id',
'4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
{code}
appears to either error out or take forever. However if I do something like:
{code}
g.withoutStrategies(RepeatUnrollStrategy.class).V().has('foo', 'id',
'4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
{code}
it works subsecond.
So something funky with {{RepeatUnrollStrategy}} is going on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1444) Benchmark bytecode->Traversal creation and implement GremlinServer cache if necessary.
[
https://issues.apache.org/jira/browse/TINKERPOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15493578#comment-15493578
]
Jeremy Hanna commented on TINKERPOP-1444:
-
It seems like this would be very similar to prepared statement cache - having
an id or hash of the bytecode to get to the equivalent traversal - presuming
like you say we parameterize them. cc [~newkek]
> Benchmark bytecode->Traversal creation and implement GremlinServer cache if
> necessary.
> --
>
> Key: TINKERPOP-1444
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1444
> Project: TinkerPop
> Issue Type: Improvement
> Components: benchmark, language-variant, process, server
>Affects Versions: 3.2.2
>Reporter: Marko A. Rodriguez
>
> Right now, when you send {{Bytecode}} to GremlinServer, it will convert the
> bytecode to a traversal either via Java reflection (Gremlin-Java) or script
> engine evaluation (e.g. Gremlin-Groovy, Gremlin-Python).
> We should see how fast the process is to go from Bytecode to Traversal and if
> its "slow" we should create a {{Map}}-cache in
> GremlinServer.
> The reasons it may be "slow" are:
> 1. {{JavaTranslator}} uses Java reflection to translate bytecode to traversal
> and that code is a little "thick" and either should be optimized (if
> possible) or, instead, bytecode/traversal translations should be cached.
> 2. {{Groovy/PythonTranslator}} uses string construction to generate a script
> from the bytecode. While that script may be cached, it would be good if we
> have a cache prior to that which simply just grabs the traversal from a
> bytecode cache.
> I think that we will definitely want a cache as it should make things fast,
> but it will be good to know how much faster prior to diving into such work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TINKERPOP-1037) Gremlin shell output coloring
[ https://issues.apache.org/jira/browse/TINKERPOP-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428192#comment-15428192 ] Jeremy Hanna edited comment on TINKERPOP-1037 at 8/19/16 1:37 PM: -- Great to see all of this come together. Thanks [~rdale] [~spmallette] [~dkuppitz] [~okram]! was (Author: jeromatron): Great to see all of this come together. Thanks all! > Gremlin shell output coloring > - > > Key: TINKERPOP-1037 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1037 > Project: TinkerPop > Issue Type: Improvement > Components: console >Affects Versions: 3.1.0-incubating >Reporter: Jeremy Hanna >Priority: Trivial > > In order to increase the readability of the output from the gremlin shell, it > would be nice to have some coloring in the output. For example coloring the > edges in the textual output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1037) Gremlin shell output coloring
[ https://issues.apache.org/jira/browse/TINKERPOP-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15428192#comment-15428192 ] Jeremy Hanna commented on TINKERPOP-1037: - Great to see all of this come together. Thanks all! > Gremlin shell output coloring > - > > Key: TINKERPOP-1037 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1037 > Project: TinkerPop > Issue Type: Improvement > Components: console >Affects Versions: 3.1.0-incubating >Reporter: Jeremy Hanna >Priority: Trivial > > In order to increase the readability of the output from the gremlin shell, it > would be nice to have some coloring in the output. For example coloring the > edges in the textual output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
