Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Thu, 8 Dec 2016 18:38:59 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.13023474.1480140997000.475120.1481222339363@Atlassian.JIRA>
In-Reply-To: <JIRA.13023474.1480140997000@Atlassian.JIRA>
References: <JIRA.13023474.1480140997000@Atlassian.JIRA> <JIRA.13023474.1480140997450@arcas>
Subject: [jira] [Commented] (DRILL-5070) Code gen: create methods in fixed
 order to allow test verification
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 08 Dec 2016 18:39:01 -0000


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

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

Github user jinfengni commented on the issue:

    https://github.com/apache/drill/pull/684
  
    It's fine to have fixed order for the generated methods. I'm not sure if it's appropriate to enforce  "golden" copy in the new tests. The golden copy is just one implementation in the current code; people may change the implementation in the future, and it's likely these new testcases will fail. The person to make the change in the future will have to deal with the overhead.
    
    The question is what benefit we get from enforcing such "golden" copy in the testcases.  


> Code gen: create methods in fixed order to allow test verification
> ------------------------------------------------------------------
>
>                 Key: DRILL-5070
>                 URL: https://issues.apache.org/jira/browse/DRILL-5070
>             Project: Apache Drill
>          Issue Type: Bug
>    Affects Versions: 1.8.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>            Priority: Minor
>
> A handy technique in testing is to compare generated code against a "golden" copy that defines the expected results. However, at present, Drill generates code using the method order returned by {{Class.getDeclaredMethods}}, but this method makes no guarantee about the order of the methods. The order varies from one run to the next. There is some evidence [this link|http://stackoverflow.com/questions/28585843/java-reflection-getdeclaredmethods-in-declared-order-strange-behaviour] that order can vary even within a single run, though a quick test was unable to reproduce this case.
> If method order does indeed vary within a single run, then the order can impact the Drill code cache since it compares the sources from two different generation events to detect duplicate code.
> This issue appeared when attempting to modify tests to capture generated code for comparison to future results. Even a simple generated case from {{ExpressionTest.testBasicExpression()}} that generates {{if(true) then 1 else 0 end}} (all constants) produced methods in different orders on each test run.
> The fix is simple, in the {{SignatureHolder}} constructor, sort methods by name after retrieving them from the class. The sort ensures that method order is deterministic. Fortunately, the number of methods is small, so the sort step adds little cost.


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