[
https://issues.apache.org/jira/browse/TINKERPOP3-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pieter martin updated TINKERPOP3-766:
-------------------------------------
Description:
B_O_P_S_SE_SL_Traverser.path variable is currently immutable.
Following on a discussion earlier on the mailing list it needs to be mutable to
ensure that the path reflects the correct state when labeled steps have been
collapsed into one optimized step.
An indication of how I am using this at the moment in an optimized 'compiled'
step is as follows,
{code}
@Override
protected Traverser<E> processNextStart() {
while (true) {
if (this.iterator.hasNext()) {
Pair<E, Map<String, Object>> next = this.iterator.next();
E e = next.getLeft();
Map<String, Object> labeledObjects = next.getRight();
//split before setting the path.
//This is because the labels must be set on a unique path for
every iteration.
Traverser.Admin<E> split = this.head.split(e, this);
for (String label : labeledObjects.keySet()) {
//If there are labels then it must be a
B_O_P_S_SE_SL_Traverser
B_O_P_S_SE_SL_Traverser b_o_p_s_se_sl_traverser =
(B_O_P_S_SE_SL_Traverser)split;
b_o_p_s_se_sl_traverser.setPath(split.path().extend(labeledObjects.get(label),
new HashSet<>(Collections.singletonList(label))));
}
return split;
} else {
this.head = this.starts.next();
this.iterator = this.flatMapCustom(this.head);
}
}
}
{code}
was:
B_O_P_S_SE_SL_Traverser.path variable is currently immutable.
Following on a discussion earlier on the mailing list it needs to be mutable to
ensure that the path reflects the correct state when labeled steps have been
collapsed into one optimized step.
An indication of how I am using this at the moment in an optimized 'compiled'
step is as follows,
{code}
@Override
protected Traverser<E> processNextStart() {
while (true) {
if (this.iterator.hasNext()) {
Pair<E, Map<String, Object>> next = this.iterator.next();
E e = next.getLeft();
Map<String, Object> labeledObjects = next.getRight();
//split before setting the path.
//This is because the labels must be set on a unique path for
every iteration.
B_O_P_S_SE_SL_Traverser split = (B_O_P_S_SE_SL_Traverser)
this.head.split(e, this);
for (String label : labeledObjects.keySet()) {
split.setPath(split.path().extend(labeledObjects.get(label), new
HashSet<>(Arrays.asList(label))));
}
return split;
} else {
this.head = (B_O_P_S_SE_SL_Traverser) this.starts.next();
this.iterator = this.flatMapCustom(this.head);
}
}
}
{code}
> Make B_O_P_S_SE_SL_Traverser.path mutable
> -----------------------------------------
>
> Key: TINKERPOP3-766
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-766
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.0.GA
> Reporter: pieter martin
> Assignee: Marko A. Rodriguez
>
> B_O_P_S_SE_SL_Traverser.path variable is currently immutable.
> Following on a discussion earlier on the mailing list it needs to be mutable
> to ensure that the path reflects the correct state when labeled steps have
> been collapsed into one optimized step.
> An indication of how I am using this at the moment in an optimized 'compiled'
> step is as follows,
> {code}
> @Override
> protected Traverser<E> processNextStart() {
> while (true) {
> if (this.iterator.hasNext()) {
> Pair<E, Map<String, Object>> next = this.iterator.next();
> E e = next.getLeft();
> Map<String, Object> labeledObjects = next.getRight();
> //split before setting the path.
> //This is because the labels must be set on a unique path for
> every iteration.
> Traverser.Admin<E> split = this.head.split(e, this);
> for (String label : labeledObjects.keySet()) {
> //If there are labels then it must be a
> B_O_P_S_SE_SL_Traverser
> B_O_P_S_SE_SL_Traverser b_o_p_s_se_sl_traverser =
> (B_O_P_S_SE_SL_Traverser)split;
>
> b_o_p_s_se_sl_traverser.setPath(split.path().extend(labeledObjects.get(label),
> new HashSet<>(Collections.singletonList(label))));
> }
> return split;
> } else {
> this.head = this.starts.next();
> this.iterator = this.flatMapCustom(this.head);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)