db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4587) Add tools for improved analysis and understanding of query plans and execution statistics
Date Tue, 10 Aug 2010 13:01:25 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896873#action_12896873

Kristian Waagan commented on DERBY-4587:


As part of some other work, I plan to take the PlanExporter for a spin.
I think such a tool has the potential to significantly improve the user friendliness
of Derby.

First, I have not followed development closely, and since I'm short on time at
the moment, I don't have the time to investigate too much. However, I'm posting
my comments in case they can be useful.
Below are some comments originating from looking at the code. Some of them are
nits, use your own judgement.

 a) The classes have no ASF license header.
    I will address this under DERBY-4764 together with some other files.

--- AccessDatabase
 b) Would it be better to use dbUrl.indexOf("://") to reduce the chance of
    mistakenly using the client driver instead of the embedded driver?
    Getting // can easily happen during scripting, for instance.
 c) The code is suspectible to some forms of SQL injection attacks.
    A quick look doesn't reveal anything severe, but in general it is wise to
    use either prepared statements or to validate the user input (i.e.,
    verify through meta data calls that the specified schema is indeed an
    existing schema.
 d) @author tags aren't used in the Derby code base
 e) Seems to be the private final variables could be static as well (also,
    many people prefer constants to be in upper case).
 f) Is it correct to shut down the database?
    I'd say not, and would be more comfortable either simply not doing it or
    have an option for it.

--- PlanExporter
 g) deleteFile is a potential security hole, allowing users to
    delete Derby files at will (I don't know which permissions the tool is
    running with by default). At the very least it should be made private,
    since it is used only within that single class.

--- TreeNode
 h) Class should be package-private.
 i) All Java objects implicitly inherit java.lang.Object. Is there a reason why
    it has been made explicit?
 j) Use of new String() is discouraged.
 k) Is thre a reason why depth is a String?

--- CreateHTMLF l) Missing class JavaDoc (short description of what it does).
 m) For convenience, it may be better to convert the HTML file name to upper-
    case and do endsWith(".HTML"). That way, you support mixed case as well.

--- CreateXMLFile
 n) You may want to unwrap the PrivilegedActionException, casting it to
    IOException (since that's the only checked exception that can occur).
    It makes the API slightly cleaner.
 o) I'm not sure what the community's take on the contents of the variable
    "comment" is.
 p) Has using a specific character encoding for the output file been discussed?
    String.getBytes() uses the default encoding on the platform.

I'm going to take the tool for a spin as well, but decided to post my comments
so far right away. As you mentioned, the number of comments under this issue is
getting very large, it might be better to track follow-up work in a separate

I'm excited to see if I can understand why one of the Derby tests fails with a
patch of mine by looking at the output of the PlanExporter. I just have to
hook it into the test itself, and then there's the problem that the Derby
JUnit framework (or rather SupportFilesSetup) deletes anything written to the
support files directories...

Thanks :)

> Add tools for improved analysis and understanding of query plans and execution statistics
> -----------------------------------------------------------------------------------------
>                 Key: DERBY-4587
>                 URL: https://issues.apache.org/jira/browse/DERBY-4587
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Tools
>            Reporter: Bryan Pendleton
>            Assignee: C.S. Nirmal J. Fernando
>         Attachments: AdavancedXSL-mouseover.jpg, advancedViewXSL.xsl, advancedViewXSL.xsl,
advancedViewXSL2.xsl, advancedXSL-1.jpg, advancedXSL-2.jpg, advancedXSL-3.jpg, basic_html-2.2.jpg,
basic_html-2.3.jpg, basic_html-2.jpg, basic_html-3.jpg, basic_html-4.1.jpg, basic_html-4.2.jpg,
Derby Query Plan Screen Shot 2.jpg, DERBY-4587-javadoc_fix.diff, DERBY-4587-tool-2.diff, DERBY-4587-tool-3.diff,
DERBY-4587-tool-4.diff, DERBY-4587-tool-5.diff, DERBY-4587-tool-6.diff, DERBY-4587-tool-7-b.diff,
DERBY-4587-tool-7.diff, DERBY-4587-tool-8.diff, DERBY-4587-tool-9.1.diff, DERBY-4587-tool-9.2.diff,
DERBY-4587-tool-9.3.diff, DERBY-4587-tool-9.4.diff, DERBY-4587-tool-9.5.diff, DERBY-4587-tool-9.6.diff,
DERBY-4587-tool-9.7.diff, DERBY-4587-tool-9.7.diff, DERBY-4587-tool-9.diff, DERBY-4587-tool-test1.diff,
DERBY-4587-tool-test2.diff, DERBY-4587-tool.diff, derby-logo.png, Derby_Query_Plan_Screen_Shot.jpg,
PostgreSQL license.jpg, Read_Me.txt, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg,
Simple HTML View (Pure XSL).jpg, Source.rar, test.xml, test4.xsl, vanilla_html.xsl, vanilla_html.xsl,
vanilla_html.xsl, vanilla_html.xsl, vanilla_html.xsl, xml_doc_screenshot.jpg, xml_doc_screenshot.jpg
> I think it would be great to see some work in the area of tools for helping
> with the analysis of complex query execution. Quite frequently, users of
> Derby have trouble comprehending (a) how their query is being translated
> into a query plan by the optimizer, and (b) what the execution-time resource
> usage of the various parts of the query is.
> There are low-level features in Derby which capture this information and
> record it, such as logQueryPlan, and the XPLAIN tables, but there is a lot
> of opportunity for designing higher-level tools which can process the query
> plan and execution statistics information and present it in a more
> comprehensible fashion. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message