[
https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682632#comment-13682632
]
Rick Hillegas commented on DERBY-6256:
--------------------------------------
I wanted to share some more thoughts about the boundary between derby.jar and
derbytools.jar. In my experience, every real SQL application needs a tool like
ij for ongoing maintenance and tuning. Between releases of your application,
you always need to pose queries which aren't in the application yet or which
you wouldn't expose to your end-users. This experience has been confirmed by
the structure of JES, the small device stack which my company sells. JES is
supposed to run on resource-constrained devices; and it contains both derby.jar
and derbytools.jar. Moving code between derby.jar and derbytools.jar will not
affect Derby's static footprint on JES. And I doubt that moving code between
derby.jar and derbytools.jar would affect Derby's static footprint for any real
small device application.
Looking at the sizes of the 10.10 jar files, you can see that derbytools.jar is
less than 1/10 the size of derby.jar. Moving code from derby.jar to
derbytools.jar doesn't even significantly affect the size of derby.jar.
That's not the point of derbytools.jar.
I believe that the point of derbytools.jar is to hold code which runs BOTH on
the client and on the server. All of the programs in derbytools.jar behave that
way.
I think that derbytools.jar is the wrong location for code which only runs
server-side.
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
