GitHub user xuchuanyin opened a pull request:

    https://github.com/apache/carbondata/pull/2565

    [HotFix][CARBONDATA-2788][BloomDataMap] Revert optimization for blockletId 
in rebuilding datamap

    We found querying huge data with rebuilding bloom datamap will give
    incorrect result. The root cause is that the blockletId in
    ResultCollector is wrong. (This was introduced in PR2539)
    We will revert the previous modification for this. Now it is checked and
    works fine.
    
    Be sure to do all of the following checklist to help us incorporate 
    your contribution quickly and easily:
    
     - [ ] Any interfaces changed?
     
     - [ ] Any backward compatibility impacted?
     
     - [ ] Document update required?
    
     - [ ] Testing done
            Please provide details on 
            - Whether new unit test cases have been added or why no new tests 
are required?
            - How it is tested? Please attach test report.
            - Is it a performance related change? Please attach the performance 
test report.
            - Any additional information to help reviewers in testing this 
change.
           
     - [ ] For large changes, please consider breaking it into sub-tasks under 
an umbrella JIRA. 
    


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/xuchuanyin/carbondata 
0726_revert_rebuild_rdd_blockletno

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/carbondata/pull/2565.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 #2565
    
----
commit 8889078ea9d1328366dc27d633b3f5ebf1906322
Author: xuchuanyin <xuchuanyin@...>
Date:   2018-07-26T15:22:58Z

    Revert optimize blockletId in rebuilding datamap
    
    We found querying huge data with rebuilding bloom datamap will give
    incorrect result. The root cause is that the blockletId in
    ResultCollector is wrong. (This was introduced in PR2539)
    We will revert the previous modification for this. Now it is checked and
    works fine.

----


---

Reply via email to