db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C.S. Nirmal J. Fernando (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4587) Add tools for improved analysis and understanding of query plans and execution statistics
Date Thu, 15 Apr 2010 18:54:50 GMT

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

C.S. Nirmal J. Fernando commented on DERBY-4587:
------------------------------------------------

Hi Bryan,

Here I quote from Derby developer's guide:

XML data types and operators

Derby supports the XML data type and a set of operators that work with the XML data
type, but does not provide JDBC support for the XML data type. The XML data type and
operators are based on a small subset of the SQL/XML specification.
The XML data type and operators are defined only in the SQL layer.
There is no JDBC-side support for XML data types. It is not possible to bind directly
into an XML value or to retrieve an XML value directly from a result set. Instead, you
must bind and retrieve the XML data as Java strings or character streams by explicitly
specifying the appropriate XML operator as part of the SQL statements:

• Use the XMLPARSE operator for binding data into XML values.
• Use the XMLSERIALIZE operator to retrieve XML values from a result set.

Additionally, there is no JDBC metadata support for the XML data type.
The XML data type is not allowed in any of the clauses or operations that are described
in the section on expressions on LONG data types in Derby and standards.
For the XML operators to work properly, Derby requires that a JAXP parser, such as
Apache Xerces, and Apache Xalan are included in the Java classpath. If either the parser
or Xalan are missing from the classpath, Derby disallows any XML-related operations.
Classpath and version issues

Most Java Virtual Machines (JVMs) that are version 1.4 or later have a JAXP parser
embedded in the JVM. If you are using one of these JVMs, you may not need to add any
classes to your classpath. Some exceptions exist:

• In most version 1.4.2 JVMs, the version of Xalan that comes with the JVM is
not new enough, so you must override the version of Xalan in the JVM with a
newer version by using the Endorsed Standards Override Mechanism described
at http://java.sun.com/j2se/1.4.2/docs/guide/standards/. To use this mechanism,
download and install a binary distribution of Xalan from Apache and set the system
property java.endorsed.dirs to point to the Xalan installation directory.

• After JVM version 1.4, Sun renamed the JAXP packages. Derby cannot find these
renamed packages. If you are using a Sun JVM later than version 1.4, download
and install a binary distribution of Xalan from Apache and place the xalan.jar
file in your classpath. The xalan.jar file automatically puts into the classpath the
other required jars that are in the same directory.


===================================================================

As you can see this needed XALAN.jar inserted into the CLASSPATH. 

>Each time we ran a statement such as SELECT XMLSERIALIZE(c) FROM xpl 
>we'd get a little "XML fragment", is that right? Or would get get an entire 
>XML document at that point? 

I think it's a XML fragment not a whole document. Will look for further details.

I'll try to come up with a pseudo code in coming days, I think it's better if we can first
come to a conclusion on using  XMLSERIALIZE considering  its usability, I'll read up more
on this regard. 

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: Bryan Pendleton
>         Attachments: Derby Query Plan Screen Shot 2.jpg, Derby_Query_Plan_Screen_Shot.jpg,
PostgreSQL license.jpg, Read_Me.txt, Source.rar
>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message