db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6256) Move the XmlVTI into the product.
Date Tue, 11 Jun 2013 22:21:20 GMT

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

Mike Matrigali commented on DERBY-6256:

In general I agree with kathey that we should be looking to separate tools/server with clear
well understood boundaries.  For me separate jars and separate codelines would be best.  Personally
I would rather see tools as a separate project from the derby server with maybe even a separate
release area.   The server should provide hooks for these kinds of tools, which is what I
thought the optional tool work was for, with the
destination of tools in other jars.  And the more separate the tools are (with clear server
supported interfaces), I think the more easily they can be added.  

I believe existing tools already are not as well tested and not expected to be as bullet proof
as other code, so best to make that clear to users also.  Having them in "demo" made that
very clear.
I think most of these tools are meant for developers, meant for debugging, and not meant for
production code.  As a developer I think these are useful, and understand that they are likely
not tested
in all cases.   But once they start getting documented in main product, delivered in main
product by default it gets hard to tell as a user what is the difference.  

In general I don't see these tools as moving us toward the project standards based dbms and
would rather see all tools that are developed as part of derby project to be clearly labeled
demo and use at own risk.  I would fully support a separate project with a goal of producing
production level tools and invite those that want to work on them to do so.

In the past we have also looked to add these kinds of tools in the debug only server.  Then
the production server can be compiled without the code path and code size bloat needed for
those debug tools.  We have the build tools framework for this, and the module system allows
us to create debug vs production module implementations when necessary.  And doing it this
way makes
a user start a debug server making it very clear that it is not a production mode.

> 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