[
https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682554#comment-13682554
]
Rick Hillegas commented on DERBY-6256:
--------------------------------------
Thanks for continuing the discussion about how to factor Derby into jar files,
Mike. I think this is a very fruitful discussion and we may be converging on a
definition of where the boundaries lie.
It may be useful to focus on a problem case at the intersection of all of the
concerns raised so far:
i) Runs on a small device
ii) Must be up and running 24x7
Examples of such an application might be:
A) Equipment controller in a hospital, nuclear power plant, or space station.
B) Switch in a mission-critical network.
An application like this wants a database product with the following
characteristics:
SMALL) Has a small static footprint.
COMPLETE) Contains all functionality needed for fast, concurrent multi-user
reads and writes, including complex filtering and joins.
DIAGNOSTIC) Contains all tools we provide for diagnosing and repairing
malfunctions and bad performance.
SPARE) Only faults in the features and tools it actually needs. Unneeded
features and tools should not consume CPU, memory, or other constrained
resources.
DWINDLING) Frees constrained resources when features and tools are not in use.
I think that the debug derby.jar decently addresses COMPLETE and DIAGNOSTIC. It
can be argued that it weighs too much to satisfy SMALL.
I think that the production derby.jar decently addresses SMALL and COMPLETE.
However, it does a poor job of addressing DIAGNOSTIC: it's disappointing that
we don't have line numbers in the stack traces of data-corrupting heisenbugs.
I don't think that either version of derby.jar adequately addresses SPARE and
DWINDLING. Dag's work on supporting compact profile 2 was a significant step
toward SPARE. In the Java 9 timeframe, I think that we can make more progress
toward SPARE by taking advantage of the Java Jigsaw project
(http://openjdk.java.net/projects/jigsaw/).
I don't think that we have given any significant thought to DWINDLING. This
suggests that we would need to remove some big, architectural roadblocks.
However, there may also be some low-hanging fruit to harvest in the near-term.
At some point, we may want to move this discussion to a new JIRA, whose intent
would be to clarify our jar file boundaries and map out a plan for delivering a
derby.jar which would be SMALL, COMPLETE, DIAGNOSTIC, SPARE, and DWINDLING.
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
