[
https://issues.apache.org/jira/browse/TINKERPOP3-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964008#comment-14964008
]
ASF GitHub Bot commented on TINKERPOP3-863:
-------------------------------------------
GitHub user okram opened a pull request:
https://github.com/apache/incubator-tinkerpop/pull/112
TINKERPOP3-863: Turn off bulking -- or is there something more general?
(hope not).
https://issues.apache.org/jira/browse/TINKERPOP3-863
* Added `GraphTraversalSource.withBulk(boolean)`, where `true` is default.
* Added `Traversal.Admin.addRequirement()` to allow for non-step based
assignment of traverser requirements.
* Removed `PathIdentityStep` as we can now `addRequirement(PATH)` at
`withPath()`.
* Updated the docs demonstrating how `withBulk(false)` no longer creates
weird behaviors around energy duplication.
* Added a new suite of traverser species that support
`TraverserRequirement.ONE_BULK` (code duplication is key to ensure a small
footprint in traverser serialization in OLAP).
* Added a new test case to `SackTest` that proves that bulking turned off
does not create weird behavior.
* Added new test case to ensure that `DefaultTraverserGeneratorFactory` is
producing the right traverser species for particular types of traversals.
* Updated `GryoMapper` with new traverser serializations.
* Fixed up the various pre-existing `TraverserGenerators` so that their
requirements are in alphabetical order and thus, easier to map to their name.
Testing notes:
* Full docs built and succeeded.
* Full integration tests passed.
Will updated CHANGELOG on merge.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/incubator-tinkerpop TINKERPOP3-863
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-tinkerpop/pull/112.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 #112
----
commit 9065b20618e0ee2d4c34a3f3e006abe5c42958c2
Author: Marko A. Rodriguez <[email protected]>
Date: 2015-10-19T19:02:55Z
Added GraphTraversalSource.withBulk(boolean). Added three new species of
Traverser which are optimized for no-bulk. While there is alot of code
deduplication, it will help to reduce Traverser footprint sizes (where in OLAP
this will really matter). Added a new SackTest which verifies the lack of bulk
does not duplicate energy values. Added
Traversal.Admin.addTraverserRequirement() which enables us to specify
reqiurements that are NOT in steps. This has the added benefit of being able to
remove the PathIdentityStep which was there for that reason for withPath().
Updated docs with a withBulk(false) example.
commit acd6c2c8083f4a567957628a425bc831d07f5eca
Author: Marko A. Rodriguez <[email protected]>
Date: 2015-10-19T19:12:03Z
Merge branch 'master' into TINKERPOP3-863
commit 902f49d92d482c6f6fd95c68564157e49ffe8da4
Author: Marko A. Rodriguez <[email protected]>
Date: 2015-10-19T20:29:16Z
added a test case for DefaultTraverserGeneratorFactory that ensures the
correct type of traverser is generated given particular traversals. Found a bug
with it where a more complex traverser was being used when a simpler one would
have done the trick. We can keep adding to this list as we come up with ideas
and more traverser species.
----
> [Proposal] Turn off bulking -- or is there something more general? (hope not).
> ------------------------------------------------------------------------------
>
> Key: TINKERPOP3-863
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-863
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
> Fix For: 3.1.0-incubating
>
>
> I have a general question -- sometimes you want bulking and sometimes you
> don't. Why would you no want bulking? Well, lets say you have sack being 1.0
> and you want to represent energy diffusion and thus, if a traverser splits
> and goes to two adjacent neighbors, then each sack will be 0.5. Now, lets say
> those two traverser merge on the next step (a diamond shaped graph), the
> merged traverser's sack is 1.0 (excellent!). However, its bulk is 2.
> Dah............. Then the total energy in the graph is 2.0.
> Should we simply have "bulk" and "no bulk" or do we come up with a "bulk
> merge" model where users can ONLY add bulks (current default and the only
> method), multiple bulks, min/max bulks, etc. etc…………………….. Scared that the
> generalization might be an overkill.
> The difference is:
> {code}
> g.withBulk(false)….. // binary -- don't use bulking.
> g.withBulk(true)... // default behavior that is currently just sum the bulks
> together.
> // or do we go with
> g.withBulk(mult)….. // when two traversers merge, multiply their bulks.. why
> would you do that, I have no idea, but its general.
> g.withBulk(one) … // would be like binary=false .. always merge to 1 and
> thus, one BinaryOpeartor(x,y) -> 1
> {code}
> Is this generalization of the bulk merge operator useful? Or do we say -- if
> you want to do complex functions on "energy" (bulk), you do it via
> sack........................
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
