db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendleton.de...@gmail.com>
Subject PlanExporter library requirements (DERBY-4587) (long message)
Date Tue, 20 Jul 2010 14:29:12 GMT
Hi all,

I wanted to share a few thoughts about the PlanExporter library handling.

I think that the core mission of PlanExporter is to enable the export
of query plan data in a complete and well-structured XML document, with
a documented schema, tested by our test suite.

I think that Nirmal's current patch in DERBY-4587 is extremely close
to meeting that goal. The Xalan requirements in the current patch are
primarily to do with how the XPlainStatisticsTest suite verifies the
correctness of the generated XML.

But it may be that the use of Xalan in the XplainStatisticsTest was
not ideal, and we should re-evaluate that technique. Perhaps there
is some other way to easily incorporate assertions about the correctness
of the XML documents that are generated during the test? Or, if we
can re-write the assertion logic in XplainStatisticsTest to use the
older version of Xalan that is already available in the tools/java
directory of the Derby trunk, that would be fine too. In fact, I think
that Nirmal is already considering various approaches to these problems.

Then, there are the more advanced usages of PlanExporter, which involve
further techniques for taking that generated XML data and processing
and formatting it for display and visualization of query plan behaviors.

I think we need to be cautious about how we handle external libraries
such as Xalan or JQuery in the PlanExporter functionality. Derby needs
to run on an extremely broad spectrum of JVM implementations, and it
also needs to retain its low footprint, both in code size and in
runtime resource requirements.

So I think we need to retain the basic principle that use of libraries
such as Xalan or JQuery must be as optional external libraries that
users can include if they wish for additional functionality, but also
can omit with no ill effects (except perhaps the loss of some PlanExporter
functionality). This is the way the other Derby XML-related features work.

Regarding JQuery, my expectation for dynamic HTML behaviors was that the
transformation of XML into well-formatted and dynamic HTML would be
performed entirely by the web browser, and would not involve any Java
code at all. I think that modern web browsers can do all the processing
of the XML entirely in the client.

I thought that we might provide one or more XSL stylesheets,
which were automatically invoked by the browser using a mechanism
such as <?xml-stylesheet> ( http://www.w3.org/TR/xml-stylesheet/ ), and
I thought that a user who wished to combine JQuery or any other external
AJAX-style library for dynamic browser behaviors would be providing and
hosting the JavaScript libraries in their own web browser environment,
not in something provided by us.

If is is possible to provide a Java-hosted mechanism for doing this, such
as the "-html" technique that Nirmal's latest patch provides, I think this
would be worth doing, but I think that we can provide a very rich and
full-featured visualization environment inside the web browser, using
just the XML export features of PlanExporter, and so I think that focusing
on making that code path solid and complete is of the most benefit to
the Derby community.



View raw message