asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luo Chen (Code Review)" <>
Subject Change in asterixdb[master]: Add Create Secondary BTree for Correlated Datasets
Date Fri, 16 Jun 2017 16:33:29 GMT
Luo Chen has posted comments on this change.

Change subject: Add Create Secondary BTree for Correlated Datasets

Patch Set 1:


 > It looks that new bulkload code hasn't actually been run?
 > Check the following method in IndexUtil:
 > public static JobSpecification buildSecondaryIndexLoadingJobSpec(Dataset
 > dataset, Index index,
 > MetadataProvider metadataProvider) throws AlgebricksException {
 > SecondaryIndexOperationsHelper secondaryIndexHelper =
 > SecondaryIndexOperationsHelper.createIndexOperationsHelper(dataset,
 > index, metadataProvider,
 > physicalOptimizationConfig);
 > return secondaryIndexHelper.buildLoadingJobSpec();
 > }
 > That shows how harmful the static method is?  Maybe it's time to
 > refactor the SecondaryIndexHelper using the factory pattern?
File asterixdb/asterix-app/src/main/java/org/apache/asterix/app/translator/

PS10, Line 959: x = MetadataManager.INSTANCE.beginTransaction();
> Inside this method, IndexUtil still uses the old SecondaryIndexOperationsHe
Done. Previously I changed the IndexUtil to use SecondaryCorrelatedIndexOperationsHelper whenever
necessary, but the change was somehow reverted...
File asterixdb/asterix-app/src/test/resources/runtimets/queries/dml/using-correlated-prefix-merge-policy-with-feed/using-correlated-prefix-merge-policy-with-feed.1.ddl.aql:

PS10, Line 21:  the correlated prefix merge policy guarantees that disk components of
             :  * the primary index and the secondary indexes of a dataset are always aligned.
> It only tests the query correctness of correlated indexes?  Disk layout is 
These integration tests only test the query correctness not the disk layout for now. I couldn't
think of a way to test disk layout only using these queries... Maybe using unit tests for
each HyrackOperator?
File asterixdb/asterix-app/src/test/resources/runtimets/queries/temp-dataset/insert-and-scan-dataset-with-correlated-index/insert-and-scan-dataset-with-correlated-index.1.ddl.aql:

PS10, Line 20:  
> WS
File asterixdb/asterix-app/src/test/resources/runtimets/queries/temp-dataset/insert-and-scan-dataset-with-correlated-index/insert-and-scan-dataset-with-correlated-index.2.update.aql:

PS10, Line 22: deadlatch
> deadlock or dead latch?
I copied the description from insert-and-scan-dataset-with-index.2.update, where the original
description is "deadlatch".
File asterixdb/asterix-app/src/test/resources/runtimets/queries/temp-dataset/insert-and-scan-dataset-with-correlated-index/insert-and-scan-dataset-with-correlated-index.3.ddl.aql:

PS10, Line 20:  
> Set IDE to trim WS?
File asterixdb/asterix-app/src/test/resources/runtimets/queries/temp-dataset/insert-and-scan-dataset-with-correlated-index/insert-and-scan-dataset-with-correlated-index.4.query.aql:

PS10, Line 21: e we insert a materializing to prevent the possib
> materialization is no longer need.
Do we still need create secondary index on temp dataset? If no, I'll remove this test...
File asterixdb/asterix-metadata/src/main/java/org/apache/asterix/metadata/utils/

PS10, Line 89: -
> why negative here?
This ensures component_pos are in a descending order. In the disk component list, components
are ordered from newest to oldest. This order here ensures older component can be bulk loaded
first so that the component file name has a small timestamp (where we relies on the component
file timestamp to restore the component list).

I added this explanation to avoid confusion in the future.

PS10, Line 290: createIndexOperationsHelper
> It looks no one calls this method? 
I fixed this at IndexUtil.
File asterixdb/asterix-runtime/src/main/java/org/apache/asterix/runtime/operators/

PS10, Line 31: AbstractLSMSecondaryCreationNodePushable
> AbstractLSMSecondaryCreationNodePushable -> AbstractLSMSecondaryIndexCreati
File asterixdb/asterix-runtime/src/main/java/org/apache/asterix/runtime/operators/

PS10, Line 46: Creation
> Creation -> Index
File hyracks-fullstack/hyracks/hyracks-storage-am-lsm-btree/src/main/java/org/apache/hyracks/storage/am/lsm/btree/dataflow/

PS10, Line 54: return null;
> Throw UnSupportedException, if no one should call into this method for this
I think this method is actually called by

PS10, Line 60: 
> Throw UnSupportedException, if no one should call into this method for this

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I2a3435e6720f07bd6a5092d4d9ce42e8d4b7894c
Gerrit-PatchSet: 1
Gerrit-Project: asterixdb
Gerrit-Branch: master
Gerrit-Owner: Luo Chen <>
Gerrit-Reviewer: Ian Maxon <>
Gerrit-Reviewer: Jenkins <>
Gerrit-Reviewer: Jianfeng Jia <>
Gerrit-Reviewer: Luo Chen <>
Gerrit-Reviewer: Till Westmann <>
Gerrit-Reviewer: Yingyi Bu <>
Gerrit-Reviewer: abdullah alamoudi <>
Gerrit-HasComments: Yes

View raw message