[jira] [Updated] (TINKERPOP-2221) Gremlin-test failed while static type checking when use secure configuration, more cases than TINKERPOP-2201

[selfish finch (JIRA)]

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

selfish finch updated TINKERPOP-2221:
-
Priority: Minor  (was: Major)

> Gremlin-test failed while static type checking when use secure configuration, 
> more cases than TINKERPOP-2201
> 
>
> Key: TINKERPOP-2221
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2221
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: selfish finch
>Priority: Minor
>
> Same issue as described in 
> [TINKERPOP-2201|https://issues.apache.org/jira/projects/TINKERPOP/issues/TINKERPOP-2201?filter=allissues],
>  fix more scenarios encountered when run gremlin-test. The related pull 
> request will be created linked with this issue. After that, all tests inside 
> gremlin-test should not fail cause by 'static type checking'.



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

[jira] [Created] (TINKERPOP-2221) Gremlin-test failed while static type checking when use secure configuration, more cases than TINKERPOP-2201

[selfish finch (JIRA)]

selfish finch created TINKERPOP-2221:


 Summary: Gremlin-test failed while static type checking when use 
secure configuration, more cases than TINKERPOP-2201
 Key: TINKERPOP-2221
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2221
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.4.1
Reporter: selfish finch


Same issue as described in 
[TINKERPOP-2201|https://issues.apache.org/jira/projects/TINKERPOP/issues/TINKERPOP-2201?filter=allissues],
 fix more scenarios encountered when run gremlin-test. The related pull request 
will be created linked with this issue. After that, all tests inside 
gremlin-test should not fail cause by 'static type checking'.



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

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Choi (JIRA)]

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

Daniel Choi commented on TINKERPOP-2220:


[~okram] could you chime in on this?  The explanation in the 524 pull request 
above seems to imply there context carry over is intended between iterations, 
but that feels like to me it's breaking the "barrier" nature of dedup().  The 
second dedup() is reaching into the first dedup()'s context (the deduping set), 
breaking the barrier, so to speak.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Comment Edited] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Choi (JIRA)]

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

Daniel Choi edited comment on TINKERPOP-2220 at 5/16/19 6:42 PM:
-

[~okram] could you chime in on this?  The explanation in the 524 pull request 
above seems to imply context carry over is intended between iterations, but 
that feels like to me it's breaking the "barrier" nature of dedup().  The 
second dedup() is reaching into the first dedup()'s context (the deduping set), 
breaking the barrier, so to speak.


was (Author: dacho00):
[~okram] could you chime in on this?  The explanation in the 524 pull request 
above seems to imply there context carry over is intended between iterations, 
but that feels like to me it's breaking the "barrier" nature of dedup().  The 
second dedup() is reaching into the first dedup()'s context (the deduping set), 
breaking the barrier, so to speak.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Commented] (TINKERPOP-2219) Upgrade Netty version

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-2219:
-

We typically update to the latest version of things unless there is some 
specific reason not to (bug, performance problem, etc). I dont think this is a 
hard/fast rule. Given that we are doing this upgrade close to release, we might 
also consider that - latest/greatest may not be the best choice. Historically 
speaking Netty is a pretty safe upgrade for us though. 

> Upgrade Netty version
> -
>
> Key: TINKERPOP-2219
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2219
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.3.6, 3.4.1
>Reporter: Divij Vaidya
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> Please upgrade the Netty version for Tinkerpop. We are currently using a year 
> old version at 4.1.25-final.
> The new versions contain numerous bug fixes and improvements. 
> My recommendation is to move to at least a 6 month old version (since newer 
> version might be unstable and have bugs) 4.1.32-final



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

[jira] [Commented] (TINKERPOP-2219) Upgrade Netty version

[Divij Vaidya (JIRA)]

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

Divij Vaidya commented on TINKERPOP-2219:
-

[~rdale], I agree that the latest and the greatest version will have all the 
new and shiny patches, but it might also contain regressions. Hence, my 
recommendation is to move to 32 as all regressions in this version should have 
been fixed by now in the subsequent versions and would be relatively "stable" 
than the latest version. A case in point is the regression fixed in 4.1.36 
which was introduced in an earlier version [1].

Having said that, I am not aware of the upgrade policy at Tinkerpop. I would be 
happy to update my PR to the latest version if that is what is preferred.


 [1] Fix regression in CompositeByteBuf.discard*ReadBytes() 
[https://netty.io/news/2019/04/30/4-1-36-Final.html]

> Upgrade Netty version
> -
>
> Key: TINKERPOP-2219
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2219
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.3.6, 3.4.1
>Reporter: Divij Vaidya
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> Please upgrade the Netty version for Tinkerpop. We are currently using a year 
> old version at 4.1.25-final.
> The new versions contain numerous bug fixes and improvements. 
> My recommendation is to move to at least a 6 month old version (since newer 
> version might be unstable and have bugs) 4.1.32-final



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

[jira] [Commented] (TINKERPOP-2197) gremlin javascript - Error: read ECONNRESET at TLSWrap.onStreamRead - websocket error

[Jorge Bay (JIRA)]

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

Jorge Bay commented on TINKERPOP-2197:
--

Hi [~comanchero], sorry I wasn't able to check this ticket before.

This looks like a bug in the driver when the connection is being actively 
closed by the server and there's no activity.

bq. Why is the error thrown in the first place

>From the error {{ECONNRESET}} it looks like the connection is being actively 
>closed by the server after that period of inactivity.

Can you verify that the {{ping}} is being sent every 60 secs with the pongs 
being sent by the server? I think you can subscribe to the logs to obtain that.

> gremlin javascript - Error: read ECONNRESET  at TLSWrap.onStreamRead - 
> websocket error
> --
>
> Key: TINKERPOP-2197
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2197
> Project: TinkerPop
>  Issue Type: Bug
>  Components: driver, javascript
>Affects Versions: 3.4.0
> Environment: windows 10 ent, 10.016299
> nodejs 11.10.1
> gemlin javascript 3.4.0
> express 4.16.4
>Reporter: Thomas Mahringer
>Priority: Major
> Attachments: gremlin-ws-error.png
>
>
> *Environment*
>  
> I'm running a nodejs express app and connect to MSFT azure gremlin through 
> the js driver:
>  
> {code:java}
> connect() {
>  this.authenticator = new 
>   Gremlin.driver.auth.PlainTextSaslAuthenticator(
>   `/dbs/${this.config.database}/colls/${this.config.collection}`,  
>this.config.primaryKey)
>this.client = new Gremlin.driver.Client(
>  this.config.endpoint,
>  { 
>authenticator: this.authenticator, 
>traversalsource: "g", 
>rejectUnauthorized: true, 
>mimeType: "application/vnd.gremlin-v2.0+json" 
> }
> }
> );
> {code}
>  
>  
> The app calls various gremlin commands through the string + "query parameter" 
> syntax, e.g. 
> {code:java}
> await this.client.submit("g.V().hasLabel(label)", {label: "Person"});{code}
>  
> All the queries work fine but when the app is idling for about 5-10 minutes, 
> the nodejs process exits with the above error. None of my error handlers are 
> hit. 
> So I debugged the gremlin js code and found out where the error is thrown: 
> It's the error handler in gremlin/lib/driver/connection.js, which gets 
> installed in "open"
> {code:java}
> open() {
>   if (this.isOpen) {
> return Promise.resolve();
>   }
>   if (this._openPromise) {
> return this._openPromise;
>   }
>   this.emit('log', `ws open`);
>   this._ws = new WebSocket(this.url, {
> headers: this.options.headers,
> ca: this.options.ca,
> cert: this.options.cert,
> pfx: this.options.pfx,
> rejectUnauthorized: this.options.rejectUnauthorized
>   });
>   this._ws.on('message', (data) => this._handleMessage(data));
>   // *** Install error handler
>   this._ws.on('error', (err) => this._handleError(err));
> ...
> }
> _handleError(err) {
>  this.emit('log', `ws error ${err}`);
>  console.error("* Added log to improve debug 
> ")
>  this._cleanupWebsocket();
>  this.emit('error', err); // Error ist thrown here
> }{code}
>  
> In the debugger I can see that the error is caused in 
> *stream_base_commons.js:*
> {code:java}
> function onStreamRead(arrayBuffer) {
>  const nread = streamBaseState[kReadBytesOrError];
>  const handle = this;
>  const stream = this[owner_symbol];
>  stream[kUpdateTimer]();
>  if (nread > 0 && !stream.destroyed) {
>const offset = streamBaseState[kArrayBufferOffset];
>const buf = new FastBuffer(arrayBuffer, offset, nread);
>if (!stream.push(buf)) {
>  handle.reading = false;
>  if (!stream.destroyed) {
>const err = handle.readStop();
>if (err)
>  stream.destroy(errnoException(err, 'read'));
>  }
>}
>return;
>  }
>  if (nread === 0) {
>return;
>  }
>  if (nread !== UV_EOF) {
>/*Happens here  */ return stream.destroy(errnoException(nread, 
> 'read'));
>  }
> ...
> }
> {code}
>  
> So my questions are:
>  * Why is the error thrown in the first place. (After app idles for 5-10 
> minutes)
>  ** What happens in "this.emit('error', err);" in "Connection._handleError".
>  * What is the right place to catch the error? I've of course wrapped the 
> "submit" code above in try/catch (in case of async/await) or as 
> "then(...).catch()..." (in case of using the promise directly). Since the 
> error causes nodejs to exit, it's quite bad.:) 
>  ** As it all happens asynchronously, I would need something like an 
> "onError" handler. But the web socket and its handler 
> (this._ws.on('error')...) are within the  "Connection" class.
> The attached image shows the stack trace in Visual Stud

[jira] [Commented] (TINKERPOP-2219) Upgrade Netty version

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-2219:


* [Netty 4.1.36.Final 
released|https://netty.io/news/2019/04/30/4-1-36-Final.html] on 30-Apr-19
 * [Netty 4.1.35.Final 
released|https://netty.io/news/2019/04/17/4-1-35-Final.html] on 17-Apr-19
 * [Netty 4.1.34.Final 
released|https://netty.io/news/2019/03/08/4-1-34-Final.html] on 08-Mar-19
 * [Netty 4.1.33.Final 
released|https://netty.io/news/2019/01/21/4-1-33-Final.html] on 21-Jan-19
 * [Netty 4.1.32.Final 
released|https://netty.io/news/2018/11/29/4-1-32-Final.html] on 29-Nov-18

> Upgrade Netty version
> -
>
> Key: TINKERPOP-2219
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2219
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.3.6, 3.4.1
>Reporter: Divij Vaidya
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> Please upgrade the Netty version for Tinkerpop. We are currently using a year 
> old version at 4.1.25-final.
> The new versions contain numerous bug fixes and improvements. 
> My recommendation is to move to at least a 6 month old version (since newer 
> version might be unstable and have bugs) 4.1.32-final



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

[jira] [Commented] (TINKERPOP-2219) Upgrade Netty version

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-2219:


I don't quite understand the justification for going to only 4.1.32.  So are 
you saying that .32 is better because at least we know what bugs and security 
issues exist by way being fixed in .33, .34, .35, .36?

> Upgrade Netty version
> -
>
> Key: TINKERPOP-2219
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2219
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.3.6, 3.4.1
>Reporter: Divij Vaidya
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> Please upgrade the Netty version for Tinkerpop. We are currently using a year 
> old version at 4.1.25-final.
> The new versions contain numerous bug fixes and improvements. 
> My recommendation is to move to at least a 6 month old version (since newer 
> version might be unstable and have bugs) 4.1.32-final



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

[jira] [Commented] (TINKERPOP-2219) Upgrade Netty version

[Robert Dale (JIRA)]

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

Robert Dale commented on TINKERPOP-2219:


https://netty.io/news/2018/11/29/4-1-32-Final.html

> Upgrade Netty version
> -
>
> Key: TINKERPOP-2219
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2219
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.3.6, 3.4.1
>Reporter: Divij Vaidya
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> Please upgrade the Netty version for Tinkerpop. We are currently using a year 
> old version at 4.1.25-final.
> The new versions contain numerous bug fixes and improvements. 
> My recommendation is to move to at least a 6 month old version (since newer 
> version might be unstable and have bugs) 4.1.32-final



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

[jira] [Closed] (TINKERPOP-2212) Path is not detaching properly under certain conditions

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-2212.
---
   Resolution: Fixed
Fix Version/s: 3.4.2
   3.3.7

> Path is not detaching properly under certain conditions
> ---
>
> Key: TINKERPOP-2212
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2212
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.3.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.3.7, 3.4.2
>
>
> Detachment is not behaving properly under certain conditions:
> {code}
> gremlin> 
> client.submit("g.V(1).out().path().by(unfold().fold())").all().get().get(0).getObject().get(0).get(0).properties()
> ==>vp[name->marko]
> ==>vp[age->29]
> {code}
> The embedded {{List}} seems to derail the detachment. 



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

[jira] [Commented] (TINKERPOP-2212) Path is not detaching properly under certain conditions

[ASF GitHub Bot (JIRA)]

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

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

spmallette commented on pull request #: TINKERPOP-2212 Fixed detachement 
problem in Path
URL: https://github.com/apache/tinkerpop/pull/
 
 
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Path is not detaching properly under certain conditions
> ---
>
> Key: TINKERPOP-2212
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2212
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.3.6
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> Detachment is not behaving properly under certain conditions:
> {code}
> gremlin> 
> client.submit("g.V(1).out().path().by(unfold().fold())").all().get().get(0).getObject().get(0).get(0).properties()
> ==>vp[name->marko]
> ==>vp[age->29]
> {code}
> The embedded {{List}} seems to derail the detachment. 



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

[jira] [Updated] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-2220:

Component/s: process

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

Re: N-Tuple Transactions?

[Stephen Mallette]

> without it, the same programs may have different results when executed on
different databases.

It would be nice if we could make it so that TinkerPop-level transactions
allowed for more control over the expectations of a traversal. There are
many instances where mutation oriented traversals have different results
depending on the backend and what it does from a transactional standpoint
in relation not only to the mutations but also to how it handles read
operations that might follow later in that same traversal. If we could
always assure the same result no matter what the backend was, that would be
huge. I imagine though that this "tuple-transactions" don't have any magic
to them and that building a unified transaction system in TinkerPop will
still be "hard".

On Wed, May 15, 2019 at 12:34 PM Joshua Shinavier  wrote:

> Tough question, since I have not used Akka or the actor model, but here are
> some first thoughts. From what I am reading, the trick would be to
> implement the transaction log as a CRDT
> .
> Operation-based CRDTs -- which propagate individual mutations as opposed to
> local state -- appear to be preferable if mutations are commutative. So are
> they commutative? In the "imperative" scenario I described to Stephen, no.
> In the "functional" scenario, yes, they have to be. Suppose you insert a
> vertex and also delete that vertex. The eventually consistent result of the
> transaction must be a no-op; if the vertex already exists, leave it alone.
> If it does not exist, do not create it. However, it does not matter in what
> order you perform the insert and delete -- once all operations are
> accounted for, you arrive at the correct state.
>
> Just from what I glean from Wikipedia, there appear to be a handful of
> well-known strategies for operation-based and state-based CRDTs. I do not
> know how hard it would be to support multiple strategies in the same VM,
> but in the Akka world, that seems to be the way in which you would choose
> your operational semantics.
>
> Josh
>
>
>
>
> On Wed, May 15, 2019 at 8:00 AM Marko Rodriguez 
> wrote:
>
> > Wow. I totally understood what you wrote.
> >
> > Question: What is the TransactionLog in a distributed environment?
> > e.g. Akka-driven traversers spawned from the same
> > query migrating around the cluster mutating stuff.
> >
> > Thanks for the lesson,
> > Marko.
> >
> > http://rredux.com 
> >
> >
> >
> >
> > > On May 15, 2019, at 8:58 AM, Joshua Shinavier 
> wrote:
> > >
> > > Hi Stephen,
> > >
> > > More the latter. TinkerPop transactions would be layered on top of the
> > > native transactions of the database (if any), which gives the VM more
> > > control over the operational semantics of a computation in between
> > database
> > > commits. For example, in many scenarios it would be desirable not to
> > mutate
> > > the graph at all until a traversal has completed, so that the result
> does
> > > not depend on the order of evaluation. Consider a traversal which adds
> or
> > > deletes elements as it goes. In some cases, you want writes and reads
> to
> > > build on each other, so that what you wrote in one step is accessible
> for
> > > reading in the next step. This is a very imperative style of traversal
> > for
> > > which you need to understand how the VM builds a query plan in order to
> > > predict the result. In many other cases, you might prefer a more
> > functional
> > > approach, for which you can forget about the query plan. Without
> VM-level
> > > transactions, you don't have this choice; you are at the mercy of the
> > > underlying database. The extra level of control will be useful for
> > > concurrency and parallelism, as well -- without it, the same programs
> may
> > > have different results when executed on different databases.
> > >
> > > Josh
> > >
> > >
> > >
> > >
> > > On Wed, May 15, 2019 at 6:47 AM Stephen Mallette  >
> > > wrote:
> > >
> > >> Hi Josh, interesting... we have graphs with everything from no
> > transactions
> > >> like TinkerGraph to more acid transactional systems and everything in
> > >> between - will transaction support as you describe it cover all the
> > >> different transactional semantics of the underlying graphs which we
> > might
> > >> encounter? or is this an approach that helps unify those different
> > >> transactional semantics under TinkerPop's definition of a transaction?
> > >>
> > >> On Wed, May 15, 2019 at 9:23 AM Joshua Shinavier 
> > >> wrote:
> > >> [...]
> >
> >
>

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Divij Vaidya (JIRA)]

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

Divij Vaidya commented on TINKERPOP-2220:
-

Getting an answer of 0 for this query is not a bug but intended behaviour. It 
has been discussed as part of the PR 
[https://github.com/apache/tinkerpop/pull/524] 

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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