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

Kristian Waagan commented on DERBY-4587:
----------------------------------------

Nirmal, some answers to your questions about my comments:

--- AccessDatabase 
c) Well, the easiest is probably to use PreparedStatement and ps.setString(x, 
s).
    By specifying a system table and a comment as the schema, say 
"sys.systables --", or saying "<stmt_id> and 1 = 1" in a where clause, one can 
make the tool query tables it isn't supposed to access. Nothing severe in this 
case, but it's good to be aware of these issues in general. Luckily you cannot 
specify multiple SQL statements in (most?) JDBC calls, because then you could 
easily add delete or update statements as well.
    You could also use Connection.getMetaData(), and then use one of the 
DatabaseMetaData.getSchemas() methods to verify that the schema actually exists.

--- CreateXMLFile
n) Since you know only an IOException can be thrown within the 
PrivilegedExceptionAction, you can add a try - catch block where you unwrap the 
IOException, something like this:
    try {
        // PrivilegedActionException wrapping IOException thrown here somewhere
    } catch (PrivilegedActionException pae) {
        throw (IOException)pae.getCause(); // or, according to the old API, 
pae.getException().
    }

    You can then remove PrivilegedActionException from the throws clause of the 
method.

p) I'm not quite sure. I don't have the cycles to follow up on this one right 
now, so it would be nice if someone else can give you more feedback on this. If 
you don't hear anything, it's probably not a big issue.

I also noticed that CreateHTMLFile only contains a method that could have been 
static. If you want to keep the class, you should make the no-arg constructor 
private and the getHTML-method static. Alternatively, you could move the method 
into CreateXMLFile or somewhere else. Your call :)


Regards,

> 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.10-eol_style_native.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.8-modified.diff, DERBY-4587-tool-9.8.diff, 
> DERBY-4587-tool-9.9-formatting.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.

Reply via email to