db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6256) Move the XmlVTI into the product.
Date Wed, 12 Jun 2013 17:03:21 GMT

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

Rick Hillegas commented on DERBY-6256:

Hi Mike,

Thanks for continuing this discussion. I can move the XmlVTI class into the tools jar if people
feel strongly about this. I think of it as similar to the ForeignTableVTI class, which is
already in the engine jar. It may look awkward if some of the support VTIs are in the engine
jar and some are in the tools jar.

Note that the ForeignTableVTI is intended for use in production (for ongoing data integration)
and for use by tech support during disaster recovery. From discussions on the user list, it's
clear that people use it. This is production code. In my opinion, so is the XmlVTI.

Right now there are 4 optional tools:

1) databaseMetaData - This is appropriate for use in production code and we document it.

2) foreignViews - This is also appropriate for use in production code and we document it.

3) optimizerTracing - The new xml-style tracing is intended to help diagnose performance problems
in production. We don't currently document either style of optimizer tracing. If we were to
document the old-style optimizer trace, I think that all we could tell people would be to
send us the output. I think that the xml-style trace could potentially be used to guide a
customer to the selection of optimizer overrides for working around a production problem.

4) optimizerTracingViews - Used in conjunction with xml-style optimizer tracing, this tool
can be used in production to guide a customer to a workaround.

Cloudscape/Derby has always aimed at being an easy-to-use database. But we don't deliver on
this promise when it comes to monitoring/diagnosing production problems. Monitoring and diagnostics
are areas where we have under-invested significantly. I don't know where to draw the line
between our monitoring/diagnostic tools and monitoring/diagnostic tools which might be more
appropriate for a separate Apache project. But my gut feeling is that we are very far away
from that line right now. Within our existing charter, we could devote several releases to
building out our monitoring/diagnostic apis. 

The topic of the debug engine probably deserves its own, separate discussion on derby-dev.
Derby's approach to diagnostic information is distinctive and maybe almost unique in our industry.
I can't think of any other product I use which requires me to bring down the application and
install separate software in order to run actionable diagnostics. This is clearly awkward
for database applications which need to run 24x7. Sometime in the distant past, we seem to
have confused the concepts of "development debugging" and "production diagnostics." Much of
our debug code is just for us as we develop features. But some of our debug code is meant
to be run in production in order to produce useful diagnostic information. In my opinion,
any code that could potentially be useful in production should be in the product. We shouldn't
even ship debug jars as part of our release distributions. The debug jars should only be used
during the development of Derby itself. I would not recommend isolating useful production
diagnostics in debug code.


> Move the XmlVTI into the product.
> ---------------------------------
>                 Key: DERBY-6256
>                 URL: https://issues.apache.org/jira/browse/DERBY-6256
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Tools
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-6256-01-aa-move-XmlVTI-into-product.diff, derby-6256-02-aa-allowParentTags.diff
> The XmlVTI under derbyDemo has been useful to me for many years. It has become even more
useful now that Derby supports varargs. That is because varargs make it very easy to declare
an XmlVTI. At this point, I think it is worth re-phrasing the XmlVTI in terms of varargs and
moving it into the product so that we can use it for internal table functions. There is no
rush to expose XmlVTI as part of Derby's public api, but we could consider doing that if other
people find this table function to be useful.
> The XmlVTI is a table function which turns an xml file into a tabular data set which
you can query via sql. When you declare an XmlVTI, you state the following arguments:
> 1) The url of an xml file.
> 2) The name of the element in the xml file which you want to treat as a record or row.
> 3) The names of the attributes and subelements of that record which you want to treat
as columns. Now that we have varargs, it is possible to represent this trailing argument as
a variable length argument list.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message