[
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: 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
