Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Wed, 11 Nov 2015 00:57:11 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.12908416.1445993540000.34799.1447203431421@Atlassian.JIRA>
In-Reply-To: <JIRA.12908416.1445993540000@Atlassian.JIRA>
References: <JIRA.12908416.1445993540000@Atlassian.JIRA>
 <JIRA.12908416.1445993540202@arcas>
Subject: [jira] [Commented] (DRILL-3987) Create a POC VV extraction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DRILL-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999711#comment-14999711 ] 

ASF GitHub Bot commented on DRILL-3987:
---------------------------------------

Github user jacques-n commented on the pull request:

    https://github.com/apache/drill/pull/250#issuecomment-155617242
  
    It seems like there are two points that Chris is asking about:
    
    1) The scale of this patch (is it too big?)
    2) The order of application between this patch and other patches (such as the allocator patch)
    
    On (1): other than moving files, there are virtually no functional changes in this patch and its purpose is extremely narrow in scope. (There are probably six or so separations between interface and implementation.) Yes, there are a lot of files that were moved. The patch creates five new modules and has to move the appropriate files into those directories. All changes were focused on the same purpose of modularization. I also chose to limit any refactoring required in these patches exactly to avoid this challenge. (Note the orange lines that I deferred in the attached PPT). As such, I think it is unfair to characterize a modularization patch by counting the number of files that were involved. 
    
    On (2): We typically order things in the order that they are ready to be merged. If this is a reasonable patch and is ready to be merged, it should be merged. If another patch has been reviewed, passes functional (and performance regression as appropriate) and is ready to be merged, it should be. In general, patches that are ready are ahead of patches that aren't ready.
    
    Specifically on the allocator patch, on numerous occasions we have held up commits to master (and releases) to try get the allocator patch merged. On each occasion, we've found that it isn't ready to be merged due to concurrency design challenges. Let's address those before worrying about staging of the patch. Once we get the algorithm right and everyone has signed off on that, we can figure out rebasing on master and staging in relationship to other patches. 


> Create a POC VV extraction
> --------------------------
>
>                 Key: DRILL-3987
>                 URL: https://issues.apache.org/jira/browse/DRILL-3987
>             Project: Apache Drill
>          Issue Type: Sub-task
>            Reporter: Jacques Nadeau
>            Assignee: Jacques Nadeau
>             Fix For: 1.4.0
>
>
> I'd like to start by looking at an extraction that pulls out the base concepts of:
> buffer allocation, value vectors and complexwriter/fieldreader.
> I need to figure out how to resolve some of the cross-dependency issues (such as the jdbc accessor connections).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)