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 Thu, 13 Jun 2013 18:49:21 GMT

    [ 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

Mime
View raw message