[
https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681597#comment-13681597
]
Mike Matrigali commented on DERBY-6256:
---------------------------------------
I agree that debug engine discussion is an orthogonal discussion.. I do think
Derby is unique, and I think that is good in many ways. And the reason I keep
raising the resource issues is that
I think each time we hurt a feature of Derby that is unique and does draw its
use. Derby is uniquely suited to act as an embedded application with a smaller
footprint than most other db's. It is
unique that it is written in java and is architected with modules so it has the
ability to be different things to different users. I just want to continue to
set precident that this is important, while not
blocking adding production level support for optional tools.
We created derbytools.jar for the very reason that some production level tools
were not needed by some derby applications and thus we allowed users to decide
if they wanted them or not. It is
not a production quality issue.
Derby continues to meet the needs of some very different applications.
Arguments that make sense for the 24*7 mission critical server application
probably don't apply to the embedded
lightly weight application that choose it for simple, fast, small standard
based sql function library. Of course 24*7 probably cares nothing about
footprint, and will just go ahead and load every
jar filie it could possibly need, and likely pay boot cost once in forever.
And there are a lot of DB's that provide just that, but Derby is unique in that
it works well at the low end and many DB's
don't.
So I think my thinking for what goes into derby.jar first starts at the project
charter:
Apache Derby, an Apache DB subproject, is an open source relational database
implemented entirely in Java and available under the Apache License, Version
2.0. Some key advantages include:
Derby has a small footprint -- about 2.6 megabytes for the base engine and
embedded JDBC driver.
Derby is based on the Java, JDBC, and SQL standards.
Derby provides an embedded JDBC driver that lets you embed Derby in any
Java-based solution.
Derby also supports the more familiar client/server mode with the Derby
Network Client JDBC driver and Derby Network Server.
Derby is easy to install, deploy, and use.
1) Is it an implementation of a standards based SQL or JDBC feature that can
only be implemented in the server and delivered in derby.jar.
so even though some derby applications never do updates, I would not have
the project deliver a base embedded product that moved update to a different
jar.
2) If it is reasonable for a derby application to not use a given non-standard
feature, or a feature that adds overhead to current product then would like
effort made
to not add the overhead to existing applications. For me this means at
least for things that look like tools to put them in derbytools.jar if they can
go there.
As I have said in the past it would also be great if new features that add
system cats implement themselves such that cats are not created if the feature
is
not used. Also features if at all possible should not impact those code
paths that don't use the feature.
i will address the 4 specfics in another comment.
> 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
