[GitHub] [tinkerpop] moayad86 commented on issue #1094: TINKERPOP-2195: Add finally block in HttpGremlinEndpointHandler to commit transaction

[GitHub]

We're using a custom Channelizer currently for that purpose, but it seems 
detaching the objects and including the additional data in the strategy is a 
reasonable solution.
Thanks for the information.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1094 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org

[GitHub] [tinkerpop] moayad86 commented on issue #1094: TINKERPOP-2195: Add finally block in HttpGremlinEndpointHandler to commit transaction

[GitHub]

We're using a custom Channelizer currently for that purpose, but it seems 
detaching the objects and including the additional data in the strategy is a 
reasonable solution.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1094 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org

AW: Using a bot to keep dependencies up to date

[Florian Hockmann]

> always using the most recent has been disastrous in python. our build breaks 
> all the time with no changes from us because of that style where we don't pin 
> to specific dependencies. i don't understand that model at all. i know you're 
> not saying that we blindly upgrade, i was just making a point about python 
> that is semi-related.

Understood and I agree completely that we should pin versions.

> we're not always sure of what a change in dependency will bring in terms of 
> change to the API but i agree that upgrades can take place (and as you 
> pointed out at the start, are already taking place in a more manual fashion).

IF our dependencies use semantic versioning, then this shouldn't be a problem 
as long as we don't do major version updates in our patch versions.

> Why no PR for spark, hadoop, etc? not that they would pass compilation - i'd 
> expect failures, but I'm just wondering if you knew the reason it didn't 
> catch those?

I also wondered about that as I had exactly the same expectation of immediately 
getting a failed build for these dependencies. Maybe they have a list of 
dependencies where they don't attempt an update? We can of course ask them 
about this if we decide to use this bot.

> it looks like it submits all PRs against master. what about tp33? will we 
> have to cherry-pick out of the PR to tp33, test and then merge forward to 
> master?

We can define the target branch for the PRs. So, we could set that to tp33 and 
then merge though to master like we usually do it for other PRs. (Maybe it's 
also possible to create different configurations for the different branches if 
we want to get one PR per branch.)

> i assume that you setup an account for dependabot that gets it configured at 
> our repo? I assume that the account is bound to your github account? 

Yes, I enabled dependabot for my account and could then give it access to my 
own repos which is a fork of our TinkerPop repo in this case.

> can that dependabot dashboard for "tinkerpop" be accessed by others or just 
> your account? how will that work?

I assume that Apacha Infra will have to activate GitHub bots like dependabot 
for us as that requires ownership of the GitHub organization. I hope that they 
can afterwards give us permissions to change the settings, but I'm not sure 
about that. Maybe these permissions also only work on an organization basis 
(which would include all ASF repos). Worst case would be that ASF Infra has to 
configure such a bot for us.

> i don't see much information about what the dashboard allows users to do
- could you summarize some of the options available and what we see there?

It allows to add different configurations for different languages or 
directories in a repo. We can then configure the following aspects per 
directory / language:

Update schedule: daily / weekly / monthly
Directory (important for the GLVs as that directory should contain the project 
file, like the .sln file for .NET)
Target branch
Filters: They currently only have a filter to only get security updates.
Automatic PR merging: Can be configured for only some versions (like patch 
versions, only security fixes, ...) and only for specific dependencies. (I 
don't think that we want automatic merging.)
For the GitHub PRs, we can also add default reviewers, assignees, and labels.

On top of that, the UI also allows to manually trigger an update run, 
irrespective of the configured update schedule. I used that on the first day as 
dependabot by default only creates 5 PRs per directory/language and per update 
run, but I wanted to get more PRs without having to wait several days.

-Ursprüngliche Nachricht-
Von: Stephen Mallette  
Gesendet: Mittwoch, 10. April 2019 14:41
An: dev@tinkerpop.apache.org
Betreff: Re: Using a bot to keep dependencies up to date

>
> I'm still not that experienced with Java/Maven, but the reasoning is 
> that we want to avoid dependency version conflicts for our users, right?
>

well, we just try to keep things stable as possible without introducing a 
breaking change by way of a dependency. it's not to say that we never do it, 
but it's always with done with careful consideration.


> In that case, it's specific to Java I'd say. At least for .NET, I 
> would expect a library to use recent versions of its dependencies.
>

always using the most recent has been disastrous in python. our build breaks 
all the time with no changes from us because of that style where we don't pin 
to specific dependencies. i don't understand that model at all. i know you're 
not saying that we blindly upgrade, i was just making a point about python that 
is semi-related.


> Since we add new features in our "patch versions" (we aren't doing 
> semantic versioning so those aren't actually patch versions), I think 
> it's also OK in general to update dependencies in those versions, at 
> least to a higher patch version, but I think a higher minor version 
> should also be OK if we also add 

Re: [TP4 Benchmarking] Pipes vs. Single-Threaded RxJava vs. Multi-Threaded RxJava

[Marko Rodriguez]

Hello,

> I hadn't put together that each compilation could have its own processor.
> Very cool.

Yea. This is an important aspect of TP4. We do something similar in TP3, it is 
just not so overt — and its not configurable.

In TP3, for example, SparkGraphComputer uses Spark to do “global traversals” 
and uses Pipes to do “local traversals.”

global: the root bytecode, branch bytecode, repeat bytecode.
local: single input nested bytecode.

Where this TP3-distinction falls apart is in local traversals that have complex 
global patterns inside them. For example:

g.V().where(…)

In TP3, ‘…’ is always considered a local traversal. This makes sense for 

g.V().where(out(‘knows’))

However, imagine this situation:

g.V().where(match(repeat(union)))

This is where SparkGraphComputer will throw the typical VerificationStrategy 
exception of “can’t process beyond the adjacent vertex.” Why does it do that? 
Because it relies on Pipes to do the processing and Pipes can only see the data 
within SparkGraphComputer’s StarVertex. Bummer.

*** Many unfortunate complications were introduced by this seemingly innocuous 
interface:

https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/TraversalParent.java
 


——

In TP4, we don’t make the global/local-traversal distinction as it is 
completely up to the processor provider to decide how they want to execute each 
Bytecode chunk. For example, a batch analytical processor strategy can look at 
where(…) and decide “eh, I’ll just use Pipes” or it can see that its 
“match(repeat(union))” and decide to continue to execute using its batch self. 
That explanation should leave you wondering how Spark could do that given the 
non-random access limitation of most batch processors. And if not, then you 
might be wondering — why don’t we just do that for TP3? I’ll leave the answer 
to a future post on ‘scoped traversers’ (which is big deal concept to come).

> Thanks for the benchmarking numbers. I had a tp3 inspired
> JMH-based module in progress when I saw your results so I added the two
> test traversals in. It doesn't do any parameterization of input sizes at
> this point but if you're interested in checking it out I pushed it to the
> tp4-jmh branch:
> https://github.com/apache/tinkerpop/blob/tp4-jmh/java/machine/machine-perf-test/src/main/java/org/apache/tinkerpop/benchmark/util/AbstractTraversalBenchmarkBase.java
>  
> 
> .

Awesome. Stephen is thinking through how we will do language agnostic testing 
in TP4, where our JVM-based VM will be one of many. I think when he gets that 
sorted out, we should figure out how to attach your benchmarking work to that 
same package so we can:

1. Verify the operational semantics of any TP4 VM (and underlying 
database + processor)
2. Benchmark the execution efficiency of any TP4 VM (and underlying 
database + processor)

It would be great to provide providers information such as:

TP4 .NET VM w/ LINQ+CosmosDB is 100% TP4 compliant.
The LINQ processor is in the top 90%-tile of single-machine, 
multi-threaded processors.
The CosmosDB structure is in the top 80%-tile of sharded 
transactional structures.


> RxSerialTraversalBenchmark.g_inject_unfold_incr_incr_incr_incr:g_inject_unfold_incr_incr_incr_incr·p0.50
>  sample  6.988  ms/op
> RxParallelTraversalBenchmark.g_inject_unfold_incr_incr_incr_incr:g_inject_unfold_incr_incr_incr_incr·p0.50
>  sample 11.633  ms/op
> PipesTraversalBenchmark.g_inject_unfold_incr_incr_incr_incr:g_inject_unfold_incr_incr_incr_incr·p0.50
>  sample  6.627  ms/op
> 
> RxSerialTraversalBenchmark.g_inject_unfold_repeat_times:g_inject_unfold_repeat_times·p0.50
>sample 3.592  ms/op
> RxParallelTraversalBenchmark.g_inject_unfold_repeat_times:g_inject_unfold_repeat_times·p0.50
>sample  7.897  ms/op
> PipesTraversalBenchmark.g_inject_unfold_repeat_times:g_inject_unfold_repeat_times·p0.50
>sample  3.887  ms/op

Pretty crazy how fast SerialRxJava is compared to Pipes — especially with my 
branch/repeat implementation being pretty freakin’ ghetto. I banged my head 
against the wall all yesterday morning trying to figure out how to do a loop in 
Rx. :| … have some new ideas this morning.

Thanks for the effort.

Take care,
Marko.

http://rredux.com


> On Mon, Apr 8, 2019 at 12:16 PM Marko Rodriguez  >
> wrote:
> 
>> Hi,
>> 
>> I implemented Multi-threaded RxJava this morning — 

[jira] [Commented] (TINKERPOP-2182) Remove gperfutils from Gremlin Console

[ASF GitHub Bot (JIRA)]

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

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

spmallette commented on pull request #1090: TINKERPOP-2182 Removed gperfutils 
dependencies in Console
URL: https://github.com/apache/tinkerpop/pull/1090
 
 
   
 

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


> Remove gperfutils from Gremlin Console
> --
>
> Key: TINKERPOP-2182
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2182
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.3.5
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
>
> We long ago stopped espousing the use of the groovy benchmarks/performance 
> libs in Gremlin Console. Not sure why they are still packaged in there with 
> the distribution except that the utilities plugin references the classes in 
> its auto-import. I also think they are somewhat bound to Groovy 2.4.x and 
> TinkerPop 3.4.x is on Groovy 2.5.x. I'd say it's best to remove them from 
> both {{tp33}} and {{master}} at this point. 
> Marking this with the "breaking" label because it means uses who might oddly 
> depend on {{gremlin-console}} for this dependency will need to add it 
> themselves now and not rely on it transitively. Highly unlikely I would 
> imagine. It is also breaking if folks somehow actually use these classes in 
> their use of the console.The workaround to bring these libs back in is pretty 
> simple - just use the {{:install}} command and do some imports. This can be 
> documented in the upgrade docs. Taken all together, this seems like a low 
> risk breaking change.



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

[jira] [Closed] (TINKERPOP-2182) Remove gperfutils from Gremlin Console

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-2182.
---
   Resolution: Done
Fix Version/s: 3.4.2
   3.3.7

> Remove gperfutils from Gremlin Console
> --
>
> Key: TINKERPOP-2182
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2182
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: console
>Affects Versions: 3.3.5
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
>  Labels: breaking
> Fix For: 3.3.7, 3.4.2
>
>
> We long ago stopped espousing the use of the groovy benchmarks/performance 
> libs in Gremlin Console. Not sure why they are still packaged in there with 
> the distribution except that the utilities plugin references the classes in 
> its auto-import. I also think they are somewhat bound to Groovy 2.4.x and 
> TinkerPop 3.4.x is on Groovy 2.5.x. I'd say it's best to remove them from 
> both {{tp33}} and {{master}} at this point. 
> Marking this with the "breaking" label because it means uses who might oddly 
> depend on {{gremlin-console}} for this dependency will need to add it 
> themselves now and not rely on it transitively. Highly unlikely I would 
> imagine. It is also breaking if folks somehow actually use these classes in 
> their use of the console.The workaround to bring these libs back in is pretty 
> simple - just use the {{:install}} command and do some imports. This can be 
> documented in the upgrade docs. Taken all together, this seems like a low 
> risk breaking change.



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

[GitHub] [tinkerpop] spmallette closed pull request #1090: TINKERPOP-2182 Removed gperfutils dependencies in Console

[GitHub]

[ pull request closed by spmallette ]

[ Full content available at: https://github.com/apache/tinkerpop/pull/1090 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org

[jira] [Closed] (TINKERPOP-2194) Enforcing an order on properties in one test method of ChooseTest

[stephen mallette (JIRA)]

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

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

Thanks for mentioning this. Fixed via CTR with 
https://github.com/apache/tinkerpop/commit/03234d22530d309fa76fd477e90809e7041f0cb6

> Enforcing an order on properties in one test method of ChooseTest
> -
>
> Key: TINKERPOP-2194
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2194
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.4.2
>Reporter: Moayad Alyaghshi
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.7, 3.4.2
>
>
> The test method "g_V_chooseXout_countX_optionX2L__nameX_optionX3L__valueMapX" 
> in the test class "ChooseTest" in enforcing an order on the properties. 
> According to my understanding, this's not expected from the data model.
> You can see that in the following assertion:
> {code:java}
> assertEquals(Long.valueOf(1), counts.get("{name=[marko], age=[29]}"));
> {code}
> If the order is different, then the test will fail.
>  



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

Re: Using a bot to keep dependencies up to date

[Stephen Mallette]

>
> I'm still not that experienced with Java/Maven, but the reasoning is that
> we want to avoid dependency version conflicts for our users, right?
>

well, we just try to keep things stable as possible without introducing a
breaking change by way of a dependency. it's not to say that we never do
it, but it's always with done with careful consideration.


> In that case, it's specific to Java I'd say. At least for .NET, I would
> expect a library to use recent versions of its dependencies.
>

always using the most recent has been disastrous in python. our build
breaks all the time with no changes from us because of that style where we
don't pin to specific dependencies. i don't understand that model at all. i
know you're not saying that we blindly upgrade, i was just making a point
about python that is semi-related.


> Since we add new features in our "patch versions" (we aren't doing
> semantic versioning so those aren't actually patch versions), I think it's
> also OK in general to update dependencies in those versions, at least to a
> higher patch version, but I think a higher minor version should also be OK
> if we also add features ourselves in those versions.
>

We allow new features into patch versions because we control the new
features and make choices as to whether they are "safe" or not. we're not
always sure of what a change in dependency will bring in terms of change to
the API but i agree that upgrades can take place (and as you pointed out at
the start, are already taking place in a more manual fashion). Again, I
just feel like we need to take each upgrade on a case by case basis.


> > We also typically have JIRAs for version bumps of dependencies - not
> always plugins - so if we continued with that those would be need to be
> created and CHANGELOG entries added manually after a merge i guess.
>
> Do we need a JIRA + CHANGELOG entry for all dependency updates or only for
> important ones?
> If we need them, then the bot at least notifies us of an available update
> and provides a PR for the update itself. We can then still create a JIRA
> issue + CHANGELOG entry manually if necessary.
> The notification should also include fixes for security problems in which
> case the bot sometimes also includes this information directly in the PR.
>

maybe we just need it for "important" ones. i guess that's how we've been
doing it so far...


> > kuppitz makes the good point of the mess Travis has been in lately.
>
> Is that a reason against using a bot for automation or am I
> misunderstanding your/Daniel's point here? If a Travis build fails
> non-deterministically for a PR created by a bot, then I would simply
> trigger a rebuild manually.
>

i guess that's just us railing about travisnot a reason to avoid
automation.


> We could also use such a bot only for the GLVs / some of the GLVs if we
> don't want to update dependencies in general outside of major releases
> (like 3.5.0). At least for .NET I would appreciate such a bot, but I can't
> say much for Python / JavaScript as I don't know enough about how they
> handle dependency updates.


if we use this, i think we should use it across the project. i looked at
the list of PRs that were generated by it in your fork more carefully and
it was curious that the larger version bumps weren't present. Why no PR for
spark, hadoop, etc? not that they would pass compilation - i'd expect
failures, but I'm just wondering if you knew the reason it didn't catch
those?

some more questions:

1. I see the list of commands that dependabot has - it looks like it
submits all PRs against master. what about tp33? will we have to
cherry-pick out of the PR to tp33, test and then merge forward to master?
or is there something easier?
2. i assume that you setup an account for dependabot that gets it
configured at our repo? I assume that the account is bound to your github
account? can that dependabot dashboard for "tinkerpop" be accessed by
others or just your account? how will that work?
3. i don't see much information about what the dashboard allows users to do
- could you summarize some of the options available and what we see there?

thanks!


On Wed, Apr 10, 2019 at 7:59 AM Florian Hockmann 
wrote:

> > we don't usually upgrade them in a release line unless
>
> I'm still not that experienced with Java/Maven, but the reasoning is that
> we want to avoid dependency version conflicts for our users, right?
>
> In that case, it's specific to Java I'd say. At least for .NET, I would
> expect a library to use recent versions of its dependencies.
>
> Since we add new features in our "patch versions" (we aren't doing
> semantic versioning so those aren't actually patch versions), I think it's
> also OK in general to update dependencies in those versions, at least to a
> higher patch version, but I think a higher minor version should also be OK
> if we also add features ourselves in those versions.
>
> > We also typically have JIRAs for version bumps of 

AW: Using a bot to keep dependencies up to date

[Florian Hockmann]

> we don't usually upgrade them in a release line unless

I'm still not that experienced with Java/Maven, but the reasoning is that we 
want to avoid dependency version conflicts for our users, right?

In that case, it's specific to Java I'd say. At least for .NET, I would expect 
a library to use recent versions of its dependencies.

Since we add new features in our "patch versions" (we aren't doing semantic 
versioning so those aren't actually patch versions), I think it's also OK in 
general to update dependencies in those versions, at least to a higher patch 
version, but I think a higher minor version should also be OK if we also add 
features ourselves in those versions.

> We also typically have JIRAs for version bumps of dependencies - not always 
> plugins - so if we continued with that those would be need to be created and 
> CHANGELOG entries added manually after a merge i guess.

Do we need a JIRA + CHANGELOG entry for all dependency updates or only for 
important ones?
If we need them, then the bot at least notifies us of an available update and 
provides a PR for the update itself. We can then still create a JIRA issue + 
CHANGELOG entry manually if necessary.
The notification should also include fixes for security problems in which case 
the bot sometimes also includes this information directly in the PR.

> kuppitz makes the good point of the mess Travis has been in lately. 

Is that a reason against using a bot for automation or am I misunderstanding 
your/Daniel's point here? If a Travis build fails non-deterministically for a 
PR created by a bot, then I would simply trigger a rebuild manually.

We could also use such a bot only for the GLVs / some of the GLVs if we don't 
want to update dependencies in general outside of major releases (like 3.5.0). 
At least for .NET I would appreciate such a bot, but I can't say much for 
Python / JavaScript as I don't know enough about how they handle dependency 
updates.

-Ursprüngliche Nachricht-
Von: Stephen Mallette  
Gesendet: Mittwoch, 3. April 2019 20:27
An: dev@tinkerpop.apache.org
Betreff: Re: Using a bot to keep dependencies up to date

hmm - so far i've been the bot. i run maven commands to find out what needs 
upgrading and then make decisions on when to do those upgrades as we don't 
usually upgrade them in a release line unless:

1. they are maven plugins
2. they are fixes for security problems
3. they introduce something important for our code base - like a performance 
fix or other enhancements

That said, my maven commands only deal with Java and not the GLVs so not much 
attention has been paid there unfortunately now that I think about it.
We also typically have JIRAs for version bumps of dependencies - not always 
plugins - so if we continued with that those would be need to be created and 
CHANGELOG entries added manually after a merge i guess.

I'm not completely against the idea, just pointing out some points of friction 
with what we currently do and kuppitz makes the good point of the mess Travis 
has been in lately. Utterly useless the last few weeks. If we didn't use a bot, 
at minimum it would be nice to document the manual methods for getting reports 
for the GLVs that show upgrade paths (I assume that those exist for other 
language ecosystems as they do for maven). it would be nice to hear additional 
thoughts on the matter.

Florian, thanks for taking the time to look into improving our build process.



On Wed, Apr 3, 2019 at 1:29 PM Daniel Kuppitz  wrote:

> Pretty cool, I like that (if only Travis would be a little more reliable).
>
> Cheers,
> Daniel
>
>
> On Wed, Apr 3, 2019 at 9:43 AM Florian Hockmann 
> 
> wrote:
>
> > Hi,
> >
> > we have a lot of dependencies in TinkerPop in different projects and 
> > even across different languages. That makes it hard to keep them 
> > updated which sometimes has security implications.
> >
> > I recently noticed that other open source projects use a bot that 
> > regularly checks whether any updates are available for their 
> > dependencies and then creates one PR per dependency. Just to try it 
> > out with TinkerPop, I activated such a bot on my fork:
> >
> > https://github.com/florianhockmann/tinkerpop/pulls
> >
> > and the overall result looks quite good in my opinion. It created a 
> > lot of PRs* and most could probably be directly merged. The bot can 
> > also be easily configured just by adding comments to its PR, for 
> > example to ignore a certain (major/minor/patch) version of a dependency:
> >
> >
> https://github.com/FlorianHockmann/tinkerpop/pull/24#issuecomment-4739
> 36360
> >
> > What do you think about adding such a bot for our repo?
> >
> >
> > * This is limited to only 5 PRs per day at first to not overwhelm a 
> > project with PRs.
> >
> >
> >
>

[jira] [Commented] (TINKERPOP-2143) JavaScript GLV: Support browsers

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-2143:
-

The pull request is out there but still needs some polishing for us to continue 
review and to get things merged - I've commented regarding the build issues and 
some other administrative things:

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



> JavaScript GLV: Support browsers
> 
>
> Key: TINKERPOP-2143
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2143
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Reporter: Jorge Bay
>Priority: Minor
> Attachments: query-editor.jpg
>
>
> Currently the JavaScript GLV is designed to work on Node.js runtime.
> We could consider supporting browser runtimes.



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

[GitHub] [tinkerpop] spmallette commented on issue #1094: TINKERPOP-2195: Add finally block in HttpGremlinEndpointHandler to commit transaction

[GitHub]

I assume that the additional information you are adding in the custom 
serializer is something where you do more traversing on returned objects or 
gather data from other sources? I'm not sure a serializer is the best place for 
that. A serializer should only be about transforming the data to its network 
payload form and probably shouldn't contain other logic. 

A custom strategy on the other hand, seems like a better place to keep that 
sort of logic. You could "detach" and then add your additional data (nothing 
says you are restricted to detaching only in the strategy) Or, if that seems 
unsuitable for some reason then you should probably create a custom 
`Channelizer` and your own implementation of that REST endpoint.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1094 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org

[GitHub] [tinkerpop] dimmg closed pull request #1095: Fix list deduplication for GraphSONV3d0 SetIO objectify

[GitHub]

[ pull request closed by dimmg ]

[ Full content available at: https://github.com/apache/tinkerpop/pull/1095 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org

[GitHub] [tinkerpop] dimmg opened pull request #1095: Fix list deduplication for GraphSONV3d0 SetIO objectify

[GitHub]

Fixes the logic behind removing the duplicates from a Python list.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1095 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org

[jira] [Commented] (TINKERPOP-2143) JavaScript GLV: Support browsers

[Moayad Alyaghshi (JIRA)]

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

Moayad Alyaghshi commented on TINKERPOP-2143:
-

Any news regarding this? The use case [~fdominik] mentioned is interesting for 
us, but we encountered the problem that Gremlin-javascript is not working in 
the browser.

> JavaScript GLV: Support browsers
> 
>
> Key: TINKERPOP-2143
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2143
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: javascript
>Reporter: Jorge Bay
>Priority: Minor
> Attachments: query-editor.jpg
>
>
> Currently the JavaScript GLV is designed to work on Node.js runtime.
> We could consider supporting browser runtimes.



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

[GitHub] [tinkerpop] moayad86 commented on issue #1094: TINKERPOP-2195: Add finally block in HttpGremlinEndpointHandler to commit transaction

[GitHub]

ReferenceElementStrategy or a strategy which uses DetachedFactory will solve 
the problem of detaching the objects, but we're using a custom JSON serializer 
to include additional information. I guess it's not going to be possible to 
include those information in that case.

[ Full content available at: https://github.com/apache/tinkerpop/pull/1094 ]
This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org