[jira] [Commented] (TINKERPOP-2049) Single argument with() overload

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637724#comment-16637724
 ] 

ASF GitHub Bot commented on TINKERPOP-2049:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/942
  
VOTE +1


> Single argument with() overload
> ---
>
> Key: TINKERPOP-2049
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2049
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.4.0
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
>
> Add {{with(k)}} which is equivalent of {{with(k, true}}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #942: TINKERPOP-2049 Added with(k) overload

[robertdale]

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/942
  
VOTE +1


---

[GitHub] tinkerpop issue #948: Optimizes Map with enum using the EnumMap implementati...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/948
  
That's the kind of benchmark I was looking for. I don't think it needs to 
be part of the project (these micro-benchmarks always seem to be too unstable 
and making them part of the test suite usually just makes the builds fail at 
some point) - thus a manual test is good enough.

VOTE + 1


---

[GitHub] tinkerpop issue #928: TINKERPOP-2015 Expose WebSocket configuration in Greml...

[deejvince]

Github user deejvince commented on the issue:

https://github.com/apache/tinkerpop/pull/928
  
@FlorianHockmann

Could you please post a working example on how to use the delegate with the 
driver connection with GremlinClient?


---

[jira] [Commented] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637536#comment-16637536
 ] 

ASF GitHub Bot commented on TINKERPOP-2015:
---

Github user deejvince commented on the issue:

https://github.com/apache/tinkerpop/pull/928
  
@FlorianHockmann

Could you please post a working example on how to use the delegate with the 
driver connection with GremlinClient?


> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1959) Provide a way to submit scripts to the server in gremlin-javascript

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637488#comment-16637488
 ] 

ASF GitHub Bot commented on TINKERPOP-1959:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/922
  
hi @mattallenuk - Judging from the comments it seems like the only thing 
missing here code-wise is an added test. Administratively, there's some 
documentation (reference docs, upgrade docs, changelog entry) to add for this 
feature as well. I don't mean to pressure or rush you but do you happen to have 
any idea when you might come back to this to finish up the final bits? 

I mainly ask because we are in the midst of planning the release of 3.2.10 
and 3.3.4 and we'd like to see this work of yours included. If your schedule 
doesn't allow for you to come back to this right now, perhaps I could assist in 
polishing up the final odds/ends for you? 


> Provide a way to submit scripts to the server in gremlin-javascript
> ---
>
> Key: TINKERPOP-1959
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1959
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Affects Versions: 3.2.8
>Reporter: stephen mallette
>Priority: Critical
>
> It is currently only possible to submit bytecode based requests to the server 
> with gremlin-javascript. We should also provide some means for submitting 
> scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #922: TINKERPOP-1959: Gremlin Javascript ability to send a s...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/922
  
hi @mattallenuk - Judging from the comments it seems like the only thing 
missing here code-wise is an added test. Administratively, there's some 
documentation (reference docs, upgrade docs, changelog entry) to add for this 
feature as well. I don't mean to pressure or rush you but do you happen to have 
any idea when you might come back to this to finish up the final bits? 

I mainly ask because we are in the midst of planning the release of 3.2.10 
and 3.3.4 and we'd like to see this work of yours included. If your schedule 
doesn't allow for you to come back to this right now, perhaps I could assist in 
polishing up the final odds/ends for you? 


---

[GitHub] tinkerpop pull request #941: TINKERPOP-2040 Improve flexibility of GroovyTra...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/941


---

[jira] [Closed] (TINKERPOP-2040) Improve flexibility of GroovyTranslator to handle custom types

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-2040.
---
   Resolution: Done
Fix Version/s: 3.2.10
   3.3.4
   3.4.0

> Improve flexibility of GroovyTranslator to handle custom types
> --
>
> Key: TINKERPOP-2040
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2040
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> {{GroovyTranslator}} only handles a set body of types. If for some reason 
> however an object is passed to it in the traversal that it doesn't know how 
> to properly handle you could get an invalid groovy string. It would be good 
> if it could not only handle new types but also override existing ones (not 
> sure why an override would be needed, but does't seem like a wrong thing to 
> allow).
> This change is slightly bigger than {{GroovyTranslator}} though because 
> however the override will take place it will need to be possible to use it 
> within the script engine somehow and right now it is initialized statically.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2040) Improve flexibility of GroovyTranslator to handle custom types

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637473#comment-16637473
 ] 

ASF GitHub Bot commented on TINKERPOP-2040:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/941


> Improve flexibility of GroovyTranslator to handle custom types
> --
>
> Key: TINKERPOP-2040
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2040
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: groovy
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> {{GroovyTranslator}} only handles a set body of types. If for some reason 
> however an object is passed to it in the traversal that it doesn't know how 
> to properly handle you could get an invalid groovy string. It would be good 
> if it could not only handle new types but also override existing ones (not 
> sure why an override would be needed, but does't seem like a wrong thing to 
> allow).
> This change is slightly bigger than {{GroovyTranslator}} though because 
> however the override will take place it will need to be possible to use it 
> within the script engine somehow and right now it is initialized statically.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2057) TypeError when grouping by multiple attributes

[Pierce Freeman (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637357#comment-16637357
 ] 

Pierce Freeman commented on TINKERPOP-2057:
---

Gremlin-python 3.3.3 & I believe the same for GraphSON.  Both were pulled from 
the latest mirrors.

> TypeError when grouping by multiple attributes
> --
>
> Key: TINKERPOP-2057
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2057
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.3
>Reporter: Pierce Freeman
>Priority: Major
>
> The python serialization engine fails when trying to group a path by two 
> intermediate variables:
>  
> {code:java}
> graph = Graph()
> g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin','g'))
> g.V().as_("a").out().out().as_("b").path().group().by(__.select("a", 
> "b")).unfold().toList()
> {code}
> {code:java}
> ~/tinkerpop/gremlin-python/src/main/jython/gremlin_python/structure/io/graphsonV3d0.py
>  in objectify(cls, l, reader)
> 456 while x < len(l):
> 457 new_dict[reader.toObject(l[x])] = reader.toObject(l[x + 1])
> --> 458 x = x + 2
> 459 return new_dict
> 460 
> TypeError: unhashable type: 'dict'
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2057) TypeError when grouping by multiple attributes

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637350#comment-16637350
 ] 

stephen mallette commented on TINKERPOP-2057:
-

what version of gremlin-python is this? and what version of GraphSON are you 
using?

> TypeError when grouping by multiple attributes
> --
>
> Key: TINKERPOP-2057
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2057
> Project: TinkerPop
>  Issue Type: Bug
>  Components: python
>Affects Versions: 3.3.3
>Reporter: Pierce Freeman
>Priority: Major
>
> The python serialization engine fails when trying to group a path by two 
> intermediate variables:
>  
> {code:java}
> graph = Graph()
> g = 
> graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin','g'))
> g.V().as_("a").out().out().as_("b").path().group().by(__.select("a", 
> "b")).unfold().toList()
> {code}
> {code:java}
> ~/tinkerpop/gremlin-python/src/main/jython/gremlin_python/structure/io/graphsonV3d0.py
>  in objectify(cls, l, reader)
> 456 while x < len(l):
> 457 new_dict[reader.toObject(l[x])] = reader.toObject(l[x + 1])
> --> 458 x = x + 2
> 459 return new_dict
> 460 
> TypeError: unhashable type: 'dict'
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TINKERPOP-2057) TypeError when grouping by multiple attributes

[Pierce Freeman (JIRA)]

Pierce Freeman created TINKERPOP-2057:
-

 Summary: TypeError when grouping by multiple attributes
 Key: TINKERPOP-2057
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2057
 Project: TinkerPop
  Issue Type: Bug
  Components: python
Affects Versions: 3.3.3
Reporter: Pierce Freeman


The python serialization engine fails when trying to group a path by two 
intermediate variables:

 
{code:java}
graph = Graph()

g = 
graph.traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin','g'))

g.V().as_("a").out().out().as_("b").path().group().by(__.select("a", 
"b")).unfold().toList()
{code}
{code:java}
~/tinkerpop/gremlin-python/src/main/jython/gremlin_python/structure/io/graphsonV3d0.py
 in objectify(cls, l, reader)
456 while x < len(l):
457 new_dict[reader.toObject(l[x])] = reader.toObject(l[x + 1])
--> 458 x = x + 2
459 return new_dict
460 

TypeError: unhashable type: 'dict'
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #948: Optimizes Map with enum using the EnumMap implementati...

[otaviojava]

Github user otaviojava commented on the issue:

https://github.com/apache/tinkerpop/pull/948
  
@dkuppitz do you have any benchmarks that you in the project use?

```java
for (int i = 0; i < 100; i++) {
long start = System.currentTimeMillis();
for (int index = 0; index < 100; index++) {
GraphFilter graphFilter = new GraphFilter();
assertFalse(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();
graphFilter.setEdgeFilter(__.outE("created"));
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton("created"), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();
graphFilter.setEdgeFilter(__.outE());
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();

graphFilter.setEdgeFilter(__.outE("created").has("weight", 32));
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton("created"), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();

graphFilter.setEdgeFilter(__.identity().outE("created"));
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();
graphFilter.setEdgeFilter(__.bothE());
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();
graphFilter.setEdgeFilter(__.bothE().has("weight", 
32));
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.singleton(null), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();
graphFilter.setEdgeFilter(__.bothE().limit(0));
assertTrue(graphFilter.hasEdgeFilter());
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.OUT));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.IN));
assertEquals(Collections.emptySet(), 
graphFilter.getLegallyPositiveEdgeLabels(Direction.BOTH));
//
graphFilter = new GraphFilter();

graphFilter.setEdgeFilter(__.bothE("created").has("weight", 32));

[jira] [Commented] (TINKERPOP-2056) Use NumberHelper in Compare

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637293#comment-16637293
 ] 

stephen mallette commented on TINKERPOP-2056:
-

It's breaking to 3.4.0 still though right? I wonder how we should handle this. 
Don't think we've had a situation where a change was breaking in one version 
but not another. Maybe use this ticket for the non-breaking part and create a 
separate ticket with the "breaking" label. That way when we generate release 
notes they "breaking" label will go with 3.4.0. Sorry - extra stuff, but I 
think that's the right way to do it.

> Use NumberHelper in Compare
> ---
>
> Key: TINKERPOP-2056
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2056
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.9
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The {{Compare}} enum doesn't use {{NumberHelper}}. Instead, it converts 
> numbers of differing types to {{BigDecimal}}s. That's pretty much the slowest 
> thing we can do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2056) Use NumberHelper in Compare

[Daniel Kuppitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637280#comment-16637280
 ] 

Daniel Kuppitz commented on TINKERPOP-2056:
---

Kinda related: {{Contains}} doesn't convert differing number types at all.

{noformat}
gremlin> g.V().has("age", eq(32L))
==>v[4]
gremlin> g.V().has("age", within(32L, 35L))
gremlin> 
{noformat}

The problem though: This behavior is enforced by the test suite and a change 
would be breaking. Hence I'm going to include the {{Compare}} changes in the 
{{tp32}} PR and I will create another PR for {{master/}} that also includes the 
{{Contains}} changes.

> Use NumberHelper in Compare
> ---
>
> Key: TINKERPOP-2056
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2056
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.9
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> The {{Compare}} enum doesn't use {{NumberHelper}}. Instead, it converts 
> numbers of differing types to {{BigDecimal}}s. That's pretty much the slowest 
> thing we can do.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop issue #948: Optimizes Map with enum using the EnumMap implementati...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/948
  
Although this looks like a very reasonable change and I don't have any 
objections, could you please run some benchmarks to show what we gain by this 
change?


---

[GitHub] tinkerpop pull request #948: Optimizes Map with enum using the EnumMap imple...

[otaviojava]

GitHub user otaviojava opened a pull request:

https://github.com/apache/tinkerpop/pull/948

Optimizes Map with enum using the EnumMap implementation

This PR replaces the HashMap implementation to 
[EnumMap](https://docs.oracle.com/javase/8/docs/api/java/util/EnumMap.html) 
that as its documentation says:

"A specialized Map implementation for use with enum type keys. All of the 
keys in an enum map must come from a single enum type that is specified, 
explicitly or implicitly, when the map is created. Enum maps are represented 
internally as arrays. This representation is extremely compact and efficient."

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/otaviojava/tinkerpop tp32_enum_map

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/948.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #948


commit 9e1865a98d9350451d29dc837e053109d714d7e3
Author: Otavio Santana 
Date:   2018-10-03T17:17:07Z

Optimazes Map with enum using the EnumMap implementation




---

Re: [DISCUSS] Modulated valueMap()

[Daniel Kuppitz]

Yea, that's weird. My code was actually pseudo-code, I wasn't referring to
T.id and T.label, we would have String some constants as we do for other
with() modulations. Perhaps:

valueMap().with(Tokens.all)
valueMap().with(Tokens.label)
valueMap().with(Tokens.id)


Cheers,
Daniel

On Wed, Oct 3, 2018 at 10:14 AM Stephen Mallette 
wrote:

> I thought about using with() for this in some way but figured by() was the
> right direction. i like your idea, but with(String) won't take with(label)
> or with(id) right? can we use by() again?  We already have by(T) as a
> modulator:
>
> g.V().
>   valueMap().
> by(id).
> by(label).
> by(unfold())
>
> Looks a little weird though...maybe?
>
>
> On Wed, Oct 3, 2018 at 10:19 AM Daniel Kuppitz  wrote:
>
> > Good idea! Also, when I saw the subject of your email, I thought you were
> > about to propose something like .with(label), .with(id) or .with(tokens)
> -
> > I would like that too as valueMap is the only step that takes a boolean
> > parameter that changes its behavior.
> >
> > Cheers,
> > Daniel
> >
> >
> > On Wed, Oct 3, 2018, 2:01 AM Stephen Mallette 
> > wrote:
> >
> > > valueMap() is a really convenient step:
> > >
> > > gremlin> g.V().has('person','name','marko').valueMap()
> > > ==>[name:[marko],age:[29]]
> > >
> > > or perhaps more preferably:
> > >
> > > gremlin> g.V().has('person','name','marko').valueMap('name','age')
> > > ==>[name:[marko],age:[29]]
> > >
> > > but argh - multiproperties ruin everything. so then we're forced into
> > > Gremlin acrobatics:
> > >
> > > gremlin> g.V().has('name','marko').
> > > ..1>valueMap('name','age').
> > > ..2>unfold().
> > > ..3>group().
> > > ..4>  by(keys).
> > > ..5>  by(select(values).unfold())
> > > ==>[name:marko,age:29]
> > >
> > > or as I usually recommend, use project():
> > >
> > > gremlin>
> > >
> > >
> >
> g.V().has('person','name','marko').project('name','age').by('name').by('age')
> > > ==>[name:marko,age:29]
> > >
> > > which is fine, but you pretty much have to type a lot more especially
> if
> > > there are a lot of properties to contend with. What if we were to
> > modulate
> > > valueMap() with by(Traversal) so that:
> > >
> > > g.V().has('person','name','marko').
> > >   valueMap('name','age').
> > > by(unfold())
> > >
> > > and the by() are just applied round-robin on the keys? Thoughts?
> > >
> >
>

Re: [DISCUSS] Modulated valueMap()

[Stephen Mallette]

I thought about using with() for this in some way but figured by() was the
right direction. i like your idea, but with(String) won't take with(label)
or with(id) right? can we use by() again?  We already have by(T) as a
modulator:

g.V().
  valueMap().
by(id).
by(label).
by(unfold())

Looks a little weird though...maybe?


On Wed, Oct 3, 2018 at 10:19 AM Daniel Kuppitz  wrote:

> Good idea! Also, when I saw the subject of your email, I thought you were
> about to propose something like .with(label), .with(id) or .with(tokens) -
> I would like that too as valueMap is the only step that takes a boolean
> parameter that changes its behavior.
>
> Cheers,
> Daniel
>
>
> On Wed, Oct 3, 2018, 2:01 AM Stephen Mallette 
> wrote:
>
> > valueMap() is a really convenient step:
> >
> > gremlin> g.V().has('person','name','marko').valueMap()
> > ==>[name:[marko],age:[29]]
> >
> > or perhaps more preferably:
> >
> > gremlin> g.V().has('person','name','marko').valueMap('name','age')
> > ==>[name:[marko],age:[29]]
> >
> > but argh - multiproperties ruin everything. so then we're forced into
> > Gremlin acrobatics:
> >
> > gremlin> g.V().has('name','marko').
> > ..1>valueMap('name','age').
> > ..2>unfold().
> > ..3>group().
> > ..4>  by(keys).
> > ..5>  by(select(values).unfold())
> > ==>[name:marko,age:29]
> >
> > or as I usually recommend, use project():
> >
> > gremlin>
> >
> >
> g.V().has('person','name','marko').project('name','age').by('name').by('age')
> > ==>[name:marko,age:29]
> >
> > which is fine, but you pretty much have to type a lot more especially if
> > there are a lot of properties to contend with. What if we were to
> modulate
> > valueMap() with by(Traversal) so that:
> >
> > g.V().has('person','name','marko').
> >   valueMap('name','age').
> > by(unfold())
> >
> > and the by() are just applied round-robin on the keys? Thoughts?
> >
>

[DISCUSS] ReferenceStrategy

[Stephen Mallette]

We currently have this situation where users get a fair bit of
inconsistency around the contents of graph elements depending on a matrix
of different usage options that we offer - here's just a few "options" as
examples:

1. Use embedded graph mode in OLTP and you likely get the implementation
version of a Vertex/Edge with accessible properties (e.g. TinkerVertex,
Neo4jVertex, etc)
2. Use embedded graph mode in OLAP and you get ReferenceVertex/Edge with no
properties
3. Use bytecode based requests with Gremlin Server and you get
ReferenceVertex/Edge with no properties
4. Use script based requests with Gremlin Server and you get
DetachedVertex/Edge with properties

All this chaos developed out of a healthy evolution of our view of "how
Gremlin should work and how it fits in the graph community." As I've
lamented before and I'll lament again, that if we'd foreseen "bytecode",
then a lot of things would have been more unified.

Anyway, irrespective of how we got here, I think this matrix of choices
ends up making things quite confusing for users.

To unify and simplify in 3.4.0, I think we could introduce a
ReferenceStrategy which would coerce graph elements to the "Reference".
Then we have some choices:

1. In the most extreme case, it could be installed as a default strategy.
All graphs was return the same stuff in whatever situation it was used.
Obviously, that breaks just about every test in existence and probably half
of the code on the planet that uses TinkerPop - everyone ready to not get
amazon packages delivered on time anymore over this? But, we're consistent!
:)
2. We install it as a default strategy in graphs in Gremlin Server. Still a
breaking change but at least Gremlin Server is completely consistent. Users
can uninstall the strategy if they don't like it and stuff will work as it
always did.
3. We simply supply ReferenceStrategy as an option and let users install it
for themselves to help bring greater consistency to their installations.

I think we should consider option 2. Unless someone has other options to
consider, it seems like the easiest starting point for this that will
actually have an impact. There could be devils lying in wait in the
details, but I thought I'd feel folks on a bit on the general idea.

Thanks,

Stephen

[DISCUSS] Recognizing Contributions

[Stephen Mallette]

There has been some discussion within the PMC over the last month or so
about how to recognize the various contributors to Apache TinkerPop. We
currently have this:

http://tinkerpop.apache.org/#committers

but we think some changes should occur. First, we would like to better
recognize the list of folks who contributed during a particular release
period to include:

1. git contributions for a release will be aggregated and presented in the
release notes.
2. non-code contributions to a release will be added and presented in the
release notes.

I don't know if "release notes" means CHANGELOG or Upgrade Docs or
something else - I suppose that remains up for discussion. The issue is
more about capturing these contributions better on a per-release basis.

Second, we expect to modify the website in that space given in the link
above - rather than have it read "Apache TinkerPop Committers" it will
instead be "Apache TinkerPop Contributors" and it will include both
official committers as well as "Friends of the TinkerPop" (working
title...suggest something better??).

For the committers section, individuals can keep this information up to
date themselves (because they have access to the git repository), but we
will ask for a bio update from each person every 6 months via email with a
request to indicate an "active" or "inactive" status. If you are "inactive"
it simply means that you aren't currently participating in the project.
Irrespective of being active or inactive, your name and tenure
accomplishments remain present on the front page of the web site. Being
"inactive" does not affect your status as an Apache committer/PMC member -
that remains unchanged. Should you decide that you are inactive at some
point, note that there is no special process to become "active" again - you
just have to update your bio to do so. The format of the committer section
would be basically the same as it is now but would have active and inactive
sections, sorted by date of TinkerPop commitership (or membership in the
pre-Apache days), as they are now.

The new "Friends of the TinkerPop" section will be a listing of those
people who have promoted the project in some positive capacity (e.g.
developed a third-party library that has some good benefit to the
community) but aren't committers/pmc members.

There's still a fair bit to sort out in terms of how this will be
implemented, but these are the general big picture items. Please let us
know what you think and then we can drive into details.




.

Re: [DISCUSS] 3.2.10, 3.3.4, 3.4.0 Releases

[Stephen Mallette]

Here's the latest update on 3.2.10/3.3.4 release issues:

+ TINKERPOP-2019/TINKERPOP-2043 - Possible bugs in .NET
+ TINKERPOP-1972 - Two failing tests in .NET around inject() (I can't seem
to get to the bottom of this one)
+ https://github.com/apache/tinkerpop/pull/922 - gremlin-js script
submission (critical imo - i would hold release over this)
+ TINKERPOP-2055 which should have PR soon and fixes special case numbers
in GraphSON

We'll see what other odds/ends pop up



On Thu, Sep 27, 2018 at 4:07 PM Florian Hockmann 
wrote:

> Cool, I just tried it out and it works as expected. In case anyone on
> here also wants to test the template:
>
> It must first be installed once with:
>
> dotnet new -i Gremlin.Net.Template::3.4.0-rc2 (The '::3.4.0-rc2'
> part is only necessary here because dotnet won't install pre-release
> versions otherwise.)
>
> and then a new project can be created with:
>
> dotnet new gremlin -o MyFirstGremlinProject
>
> where -o with its argument is optional and specifies the name of the
> project to create.
>
>
> Am 27.09.2018 um 16:59 schrieb Robert Dale:
> > Oh, it's its own package.  I'm all setup for it now. Thanks.
> >
> > Robert Dale
> >
> >
> > On Thu, Sep 27, 2018 at 10:53 AM Stephen Mallette 
> > wrote:
> >
> >> yeah - that part works...it's the "Template" package that failed to
> upload.
> >> i figured it out though: my API key was limited to publishing just to
> >> Gremlin.Net and not the Gremlin.Net.Template. It's there now:
> >>
> >> https://www.nuget.org/packages/Gremlin.Net.Template/
> >>
> >> On Thu, Sep 27, 2018 at 10:32 AM Robert Dale  wrote:
> >>
> >>> I got an email that states:
> >>>
> >>> The package Gremlin.Net 3.4.0-rc2
> >>>  was recently
> >>> published on NuGet Gallery by tinkerpop. If this was not intended,
> >>> please contact
> >>> support
> >>>  >.
> >>> The link works.  Looks like it worked.
> >>>
> >>> Robert Dale
> >>>
> >>>
> >>> On Thu, Sep 27, 2018 at 10:21 AM Stephen Mallette <
> spmalle...@gmail.com>
> >>> wrote:
> >>>
>  So, 3.4.0-rc2 for Gremlin.Net is published. The template attempted to
>  publish but failed with:
> 
>   [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
>  https://www.nuget.org/api/v2/package'...
>   [exec]   PUT https://www.nuget.org/api/v2/package/
>   [exec]   ServiceUnavailable
> https://www.nuget.org/api/v2/package/
>  458ms
>   [exec]   PUT https://www.nuget.org/api/v2/package/
>   [exec] 403 (The specified API key is invalid, has expired, or
> does
> >>> not
>  have permission to access the specified package.)
>   [exec]   Forbidden https://www.nuget.org/api/v2/package/ 702ms
> 
>  I'm not sure what's going on theredoes that make any sense to you,
>  Florian?
> 
> 
> 
>  On Thu, Sep 27, 2018 at 9:26 AM Florian Hockmann <
> >> f...@florian-hockmann.de
>  wrote:
> 
> > It should at least. We have never tested it, but the docs say that
> >> 'mvn
> > clean install -Dnuget' can be used to create the package. So, the
> >> other
> > Maven commands should work the same way. If it doesn't directly work
> >> or
> > if you run into any other problems, then I can also give it a try.
> >
> >
> > Am 27.09.2018 um 15:20 schrieb Stephen Mallette:
> >> uhi don't remember if there is anything special i need to do to
>  make
> >> that happen. does it just deploy with the standard deploy
> >>> instructions?
> >> On Thu, Sep 27, 2018 at 9:13 AM Florian Hockmann <
>  f...@florian-hockmann.de
> >> wrote:
> >>
> >>> Great, do you also plan to include the Gremlin.Net.Template in
> >> this
> >>> prerelease?
> >>>
> >>>
> >>> Am 26.09.2018 um 13:00 schrieb Stephen Mallette:
>  Just a quick note that I plan to do the .NET 3.4.0-rc2 release
> > tomorrow.
>  Here's the updated todo list for the 3.2.10/3.3.4:
> 
>  + TINKERPOP-2025 - https://github.com/apache/tinkerpop/pull/935
>  ready
> > to
>  merge
>  + TINKERPOP-2019/TINKERPOP-2043 - Possible bugs in .NET
>  + TINKERPOP-1906 - Make status messages/attributes from the
> >> server
>  more
>  available in .NET (maybe already done on TINKERPOP-1913 to some
>  degree)
>  + TINKERPOP-1972 - Two failing tests in .NET (I can't seem to get
> >>> to
> > the
>  bottom of this one)
>  + https://github.com/apache/tinkerpop/pull/920 - minor
> >>> refactoring,
> > just
>  had some activity on it, so it looks like this one will get in:
>  + https://github.com/apache/tinkerpop/pull/922 - gremlin-js
> >> script
>  submission (critical imo - i would hold release over this)
>  + https://github.com/apache/tinkerpop/pull/928 - this one just
> >>> 

Re: [DISCUSS] Modulated valueMap()

[Daniel Kuppitz]

Good idea! Also, when I saw the subject of your email, I thought you were
about to propose something like .with(label), .with(id) or .with(tokens) -
I would like that too as valueMap is the only step that takes a boolean
parameter that changes its behavior.

Cheers,
Daniel


On Wed, Oct 3, 2018, 2:01 AM Stephen Mallette  wrote:

> valueMap() is a really convenient step:
>
> gremlin> g.V().has('person','name','marko').valueMap()
> ==>[name:[marko],age:[29]]
>
> or perhaps more preferably:
>
> gremlin> g.V().has('person','name','marko').valueMap('name','age')
> ==>[name:[marko],age:[29]]
>
> but argh - multiproperties ruin everything. so then we're forced into
> Gremlin acrobatics:
>
> gremlin> g.V().has('name','marko').
> ..1>valueMap('name','age').
> ..2>unfold().
> ..3>group().
> ..4>  by(keys).
> ..5>  by(select(values).unfold())
> ==>[name:marko,age:29]
>
> or as I usually recommend, use project():
>
> gremlin>
>
> g.V().has('person','name','marko').project('name','age').by('name').by('age')
> ==>[name:marko,age:29]
>
> which is fine, but you pretty much have to type a lot more especially if
> there are a lot of properties to contend with. What if we were to modulate
> valueMap() with by(Traversal) so that:
>
> g.V().has('person','name','marko').
>   valueMap('name','age').
> by(unfold())
>
> and the by() are just applied round-robin on the keys? Thoughts?
>

[jira] [Commented] (TINKERPOP-1972) inject() tests are throwing exceptions in .NET GLV tests

[Florian Hockmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636983#comment-16636983
 ] 

Florian Hockmann commented on TINKERPOP-1972:
-

I just debugged the scenario 
{{g_injectX1X_chooseXisX1X__constantX10Xfold__foldX}} and the problem seems to 
be that the {{inject}} step gets an array of integers with the member {{1}} 
which isn't equal to the first argument of {{choose}} which is just the integer 
{{1}}. The full Bytecode sent to the server looks like this:
{code}
{
"step": [
[
"inject",
[
{
"@type": "g:Int32",
"@value": 1
}
]
],
[
"choose",
{
"@type": "g:Bytecode",
"@value": {
"step": [
[
"is",
{
"@type": "g:Int32",
"@value": 1
}
]
]
}
},
{
"@type": "g:Bytecode",
"@value": {
"step": [
[
"constant",
{
"@type": "g:Int32",
"@value": 10
}
],
[
"fold"
]
]
}
},
{
"@type": "g:Bytecode",
"@value": {
"step": [
[
"fold"
]
]
}
}
]
]
}
{code}
and the server returns {{10}} in this case. After removing {{[]}} around the 
{{g:Int32}} of {{inject}}, the server successfully returned {{1}}.

It looks like this is a general problem with steps that take a {{params S[]}} 
like {{Inject}} but I don't know yet how we can fix this.

BTW, debugging .NET tests is really inconvenient right now as a test server has 
to be started manually as Maven usually does that. I think something like 
[Testcontainers|https://www.testcontainers.org/] could really improve this 
situation, but that's another topic.

> inject() tests are throwing exceptions in .NET GLV tests
> 
>
> Key: TINKERPOP-1972
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1972
> Project: TinkerPop
>  Issue Type: Bug
>  Components: dotnet
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> New GLV tests were added in TINKERPOP-1963 and are generating this error:
> {code}
> Failures:
> 1) g_injectX1X_chooseXisX1X__constantX10Xfold__foldX: Failed
> System.NotSupportedException: Type is not supported.
>at System.Array.InternalCreate(Void* elementType, Int32 rank, Int32* 
> pLengths, Int32* pLowerBounds)
>at System.Array.CreateInstance(Type elementType, Int32 length)
>at 
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.BuildParameters(MethodInfo
>  method, Token token, IDictionary`2& genericParameterTypes) in 
> /home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
>  268
>at 
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversalFromTokens(IList`1
>  tokens, GraphTraversalSource g, IDictionary`2 contextParameterValues, String 
> traversalText) in 
> /home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
>  90
>at 
> Gremlin.Net.IntegrationTest.Gherkin.TraversalEvaluation.TraversalParser.GetTraversal(String
>  traversalText, GraphTraversalSource g, IDictionary`2 contextParameterValues) 
> in 
> /home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/TraversalEvaluation/TraversalParser.cs:line
>  62
>at 
> Gremlin.Net.IntegrationTest.Gherkin.CommonSteps.TranslateTraversal(String 
> traversalText) in 
> /home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Gherkin/CommonSteps.cs:line
>  101
> 2) g_injectX2X_chooseXisX1X__constantX10Xfold__foldX: Failed
> System.NotSupportedException: Type is not supported.
>at System.Array.InternalCreate(Void* elementType, Int32 rank, Int32* 
> pLengths, Int32* pLowerBounds)
>at System.Array.CreateInstance(Type elementType, Int32 length)
> 

[jira] [Commented] (TINKERPOP-2055) Provide support for special number cases like Infinity in GraphSON

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636959#comment-16636959
 ] 

ASF GitHub Bot commented on TINKERPOP-2055:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/947

TINKERPOP-2055 Support NaN and Infinity in GraphSON

https://issues.apache.org/jira/browse/TINKERPOP-2055

GraphSON wasn't supporting NaN and Infinity but Gryo was. Merging to tp33 
and forward will require some additional commits for GraphSON 3.0.

All tests pass with `docker/build.sh -t -n -i`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-2055

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/947.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #947


commit afc12bd27bc9c4c26b3ba2594c4c0810d5d76421
Author: Stephen Mallette 
Date:   2018-10-02T19:35:53Z

TINKERPOP-2055 Added support for special Double values

Includes Nan and the infinity values.

commit 854914e6e3adbf7f0854eb0fec0c3a38b61d4644
Author: Stephen Mallette 
Date:   2018-10-02T20:55:50Z

TINKERPOP-2055 Support for special numbers in python

commit 2d3041f226310379c966214461c79cf47432f4c9
Author: Stephen Mallette 
Date:   2018-10-03T08:33:40Z

TINKERPOP-2055 Added special number handling in javascript

commit b542027825fe905c0c46b81a00fe7dfd5275e8c6
Author: Stephen Mallette 
Date:   2018-10-03T09:11:56Z

TINKERPOP-2055 Added tests for .Net on special numbers

commit a083fbff62fcc38a3dae9b138f56b0d052e0c143
Author: Stephen Mallette 
Date:   2018-10-03T09:30:27Z

TINKERPOP-2055 Updated IO docs to include special numbers




> Provide support for special number cases like Infinity in GraphSON
> --
>
> Key: TINKERPOP-2055
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2055
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>
> GraphSON currently doesn't handle: {{Double.Nan}}, 
> {{Double.NEGATIVE_INFINITY}} or {{Double.POSITIVE_INFINITY}} because it has a 
> custom {{Double}} serializer that ignores those cases in GraphSON 2.0 and 
> 3.0. Not going to try to solve this for 1.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #947: TINKERPOP-2055 Support NaN and Infinity in Grap...

[spmallette]

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/947

TINKERPOP-2055 Support NaN and Infinity in GraphSON

https://issues.apache.org/jira/browse/TINKERPOP-2055

GraphSON wasn't supporting NaN and Infinity but Gryo was. Merging to tp33 
and forward will require some additional commits for GraphSON 3.0.

All tests pass with `docker/build.sh -t -n -i`

VOTE +1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-2055

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/947.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #947


commit afc12bd27bc9c4c26b3ba2594c4c0810d5d76421
Author: Stephen Mallette 
Date:   2018-10-02T19:35:53Z

TINKERPOP-2055 Added support for special Double values

Includes Nan and the infinity values.

commit 854914e6e3adbf7f0854eb0fec0c3a38b61d4644
Author: Stephen Mallette 
Date:   2018-10-02T20:55:50Z

TINKERPOP-2055 Support for special numbers in python

commit 2d3041f226310379c966214461c79cf47432f4c9
Author: Stephen Mallette 
Date:   2018-10-03T08:33:40Z

TINKERPOP-2055 Added special number handling in javascript

commit b542027825fe905c0c46b81a00fe7dfd5275e8c6
Author: Stephen Mallette 
Date:   2018-10-03T09:11:56Z

TINKERPOP-2055 Added tests for .Net on special numbers

commit a083fbff62fcc38a3dae9b138f56b0d052e0c143
Author: Stephen Mallette 
Date:   2018-10-03T09:30:27Z

TINKERPOP-2055 Updated IO docs to include special numbers




---

[jira] [Reopened] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[Florian Hockmann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Florian Hockmann reopened TINKERPOP-2015:
-

Adding another fix version apparently requires to reopen the issue.

> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[Florian Hockmann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Florian Hockmann closed TINKERPOP-2015.
---
   Resolution: Fixed
Fix Version/s: 3.4.0

> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[Florian Hockmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636858#comment-16636858
 ] 

Florian Hockmann commented on TINKERPOP-2015:
-

No, I merged it of course also to master and it will therefore also land in 
3.4.0. I just wasn't sure whether I should also tag version 3.4.0 since it's 
not clear when that will be released. But I guess that isn't really important 
for the fix version field... so, I'll also add that as the fix version, too.

> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.3.4, 3.2.10
>
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636856#comment-16636856
 ] 

stephen mallette commented on TINKERPOP-2015:
-

[~Florian Hockmann]  Is there a reason this change doesn't apply to master and 
3.4.0? fix version only shows 3.3.4 and 3.2.10.

> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.3.4, 3.2.10
>
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[Florian Hockmann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Florian Hockmann closed TINKERPOP-2015.
---
   Resolution: Fixed
Fix Version/s: 3.2.10
   3.3.4

> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
> Fix For: 3.3.4, 3.2.10
>
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #928: TINKERPOP-2015 Expose WebSocket configuration i...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/928


---

[jira] [Commented] (TINKERPOP-2015) Allow users to configure the WebSocket connections

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636765#comment-16636765
 ] 

ASF GitHub Bot commented on TINKERPOP-2015:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/928


> Allow users to configure the WebSocket connections
> --
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Major
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class 
> with default options. That is probably appropriate for most users but it 
> makes it impossible to change the config and use certain features like client 
> certificates or proxy settings.
> We could simply allow users to provide a 
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
>  object. Since it's part of .NET Standard (and not a 3rd party library) it 
> shouldn't be a problem to expose this type. This would also have the nice 
> advantage that users could immediately use new options like the 
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
>  that was just added in .NET Core 2.1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] tinkerpop pull request #920: optmizes collection copy with Collections addAl...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/920


---

[jira] [Reopened] (TINKERPOP-1906) Make ResponseException explorable

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette reopened TINKERPOP-1906:
-

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (TINKERPOP-1906) Make ResponseException explorable

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636683#comment-16636683
 ] 

stephen mallette edited comment on TINKERPOP-1906 at 10/3/18 9:36 AM:
--

This was added on TINKERPOP-1913

https://github.com/apache/tinkerpop/blob/b788201bfcc0bd4f2a5eb24a66d32be58d06583d/gremlin-dotnet/src/Gremlin.Net/Driver/Exceptions/ResponseException.cs#L57


was (Author: spmallette):
This was added on TINKERPOP-1906 

https://github.com/apache/tinkerpop/blob/b788201bfcc0bd4f2a5eb24a66d32be58d06583d/gremlin-dotnet/src/Gremlin.Net/Driver/Exceptions/ResponseException.cs#L57

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-1906) Make ResponseException explorable

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1906.
---
Resolution: Done

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-1906) Make ResponseException explorable

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1906.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.4.0

This was added on TINKERPOP-1906 

https://github.com/apache/tinkerpop/blob/b788201bfcc0bd4f2a5eb24a66d32be58d06583d/gremlin-dotnet/src/Gremlin.Net/Driver/Exceptions/ResponseException.cs#L57

> Make ResponseException explorable
> -
>
> Key: TINKERPOP-1906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1906
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: dotnet
>Affects Versions: 3.2.7
>Reporter: Roman Kreisel
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.4.0
>
> Attachments: message.txt, stacktrace.txt
>
>
> The ResponseException from Gremlin.NET doesn't give you any possibility to 
> react on the GremlinService's Response. The only content is the exception's 
> Message, which is just free text.
> It would be great, to add some fields to expose at least the HTTP ErrorCode 
> or anything else that's responded by the service.
>  
> Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a 
> "Request Rate to Large" response, in case you have high load on your 
> database. In such a case, you want to be able to detect this "error" and just 
> retry after a few milliseconds (i'm not sure, but i think even a proposal for 
> this retry-timeout is given in the response)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[DISCUSS] Modulated valueMap()

[Stephen Mallette]

valueMap() is a really convenient step:

gremlin> g.V().has('person','name','marko').valueMap()
==>[name:[marko],age:[29]]

or perhaps more preferably:

gremlin> g.V().has('person','name','marko').valueMap('name','age')
==>[name:[marko],age:[29]]

but argh - multiproperties ruin everything. so then we're forced into
Gremlin acrobatics:

gremlin> g.V().has('name','marko').
..1>valueMap('name','age').
..2>unfold().
..3>group().
..4>  by(keys).
..5>  by(select(values).unfold())
==>[name:marko,age:29]

or as I usually recommend, use project():

gremlin>
g.V().has('person','name','marko').project('name','age').by('name').by('age')
==>[name:marko,age:29]

which is fine, but you pretty much have to type a lot more especially if
there are a lot of properties to contend with. What if we were to modulate
valueMap() with by(Traversal) so that:

g.V().has('person','name','marko').
  valueMap('name','age').
by(unfold())

and the by() are just applied round-robin on the keys? Thoughts?