[
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.
Thanks,
-Rick
> 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: 10.11.0.0
> 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
